Daniel,
All of the subversion tools are used under Windows. No subversion tools
are even installed under any Linux installations.
The source code is used under Linux, but rarely edited under Linux. I
regularly use Cygwin tools (dos2unix.exe, for example), but rarely edit
files there.
You did make a minor assumption I'll correct. Files are rarely
explicitly locked. In 20 years I am the only individual here who has
ever touched these sources. Thus, I haven't locked any of the sources
before editing in over 10 years. Whatever locking that occurs, if any,
is done so magically by the tools.
Again, though, if I ever see an assertion again I'll retain the
offending file for submission with the error report.
Don
On 12/15/2022 2:05 AM, Daniel Sahlberg wrote:
Den tors 15 dec. 2022 kl 06:04 skrev Nathan Hartman
<hartman.nat...@gmail.com <mailto:hartman.nat...@gmail.com>>:
On Wed, Dec 14, 2022 at 2:24 PM Don Newbold (GSC)
<d...@generalstandards.com <mailto:d...@generalstandards.com>> wrote:
> To be clear, I have never seen any SVN related ASSERTION on any other
> occasion.
>
> The file in question is named "release.txt" and contains release
notes
> for a driver. I've got over 50 different such files and collectively
> have made perhaps 500 different commits of these files. I see the
commit
> failure on the file's parent documentation subdirectory often enough
> that I typically go to dos2unit on this file without checking to see
> what the complaint is.
>
> The property are ...
>
> EOL: native
> MIME: test/plain
> Keywords: author, date, ID, revision, URL
> needs lock: *
> No other properties are set.
>
> The file is virtually always edited under Windows using Visual Studio
> 2005. This inserts Windows style line endings. However, the file
is used
> under Linux and is run through dos2unix as part of the release
> procedure. To clarify, the file is maintained with UNIX style line
> endings, but gets Windows style line endings for newly added
lines. The
> SVN properties are set automatically based on it being a .txt file.
> Every release includes one or more other .txt files, with
identical SVN
> properties. I'm sure I see this commit failure periodically with
other
> .txt files, but they aren't changed enough for me to have
developed an
> automatic response when a commit fails.
[...]
Meanwhile, a request: If you (or anyone) sees this again, please save a
copy of the file that exposes it and then talk to us so that with your
help we could figure out what is the offending sequence and how to
reproduce it for debugging and regression testing...
The mentioning of Windows and Linux above makes me wonder if you are
using the same working copy from both Windows and Linux (WSL/Cygwin)
environments. It was discussed on the TortoiseSVN mailing list a while
ago [1] but I don't think anyone actually encountered an assertion and
I'm not able to reproduce it either. (All my experiments ended with
"E135000: Inconsistent line ending style"). The conclusion was to
maintain separate working copies for the different environments.
If you use svn:eol-style native you should be able to checkout the file
under Linux (including WSL/Cygwin) and automatically have \n line
endings without any need for conversion. When you checkout the file
under Windows (using TSVN or the svn command line tools) you will get
\r\n line endings.
Kind regards,
Daniel
[1] https://groups.google.com/g/tortoisesvn/c/6g9nucDEtlA/m/no_3CEvbAAAJ
<https://groups.google.com/g/tortoisesvn/c/6g9nucDEtlA/m/no_3CEvbAAAJ>
--
Don Newbold
256-880-8787, x110
General Standards
