Nathan,
Understood. If and when I see the assertion again I'll retain a copy of
the file and send that along with the reporting email.
Don
On 12/14/2022 11:03 PM, Nathan Hartman wrote:
On Wed, Dec 14, 2022 at 2:24 PM Don Newbold (GSC)
<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.
Ah, I see. Thanks for the clarification.
There are two separate items here.
(1) Subversion complains when you try to commit a file that (a) has the
svn:eol-style property and (b) contains a mixture of newline styles.
This is actually *correct* behavior: Since Subversion is going to
modify the file as it passes from your working copy to the repository,
to normalize all line endings to LF style, it must first make sure that
the file does not contain a mixture, since that may indicate a user
error. Consider, for example, the possibility of accidentally setting
this property on a binary file. In such a file, the CR and LF
characters (decimal 13 and 10 respectively) could be not line endings
at all, but rather part of the binary data. Changing these during a
commit operation could irrecoverably corrupt the data. As a safety
measure, Subversion won't do it unless all lines have the same line
ending style.
(2) The assertion failure. This definitely indicates a bug somewhere.
The tricky part, of course, is to find the cause, which is made much
more difficult when there isn't a reproduction script that can expose
the issue for single-step debugging, or at least a stack trace. What I
do know is that the function in question, translate_newline(), which is
part of the logic that handles line ending and keyword translation and
de-translation, both of which the file in question has, is somehow
receiving 'newline_buf' contents that do not match one of the allowed
values "\n", "\r", or "\r\n". The data in this 2-character buffer is
coming from the file being (de-)translated, so it seems that somehow,
some sequence of '\n', '\r', and/or '$' (for keywords) that was present
in the file before you ran dos2unix confused things. It seems that
whatever happened is extremely rare, since this is the only report of
this assertion failure that I can find anywhere, except for one that
occurred in testing with an intermediate version of this logic during
its development a really long time ago [1]. I could go ahead and file
this as a bug in the issue tracker in case others encounter this
assertion failure. That could help to gather more data about it if
other users encounter it.
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...
[1] https://lists.apache.org/thread/grcn9pvn1m1706j3s8znp4zqox5tlhfc
Thanks,
Nathan
--
Don Newbold
256-880-8787, x110
General Standards
