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
