On 6/14/07, Lasse Vågsæther Karlsen <lasse@vkarlsen.no> wrote:
> On 6/14/07, Lübbe Onken <l.onken@rac.de> wrote:
> > I wrote:
> >
> > > Hi Lasse,
> > ...
> > >> Upon reading in on this, it seems SVN will keep the files in an
> > >> internal state with only the LF characters in place,
> > >
> > > ...if the svn:eol-style property is set. If the property is
> > > not set, svn
> > > neither reports inconsistencies nor touches the line endings.
>
> Then the question again remains: what specifically won't work for me
See below for what I found out about the line endings setting.
> > Which in part contradicts my following observation with the current nightly
> >
> > > ...
> > > When I do this with a current nightly, the commit fails and I get an
> > > "inconsistent newlines" error message in the commit dialog.
> > > This happens every time i try. I can't commit this file and the file
> > > doesn't have the svn:eol-style property set.
>
> And this probably works too, but it seems that the problem is that the
> line endings check "bleeds over" from one file to another in some
> cases so that a file that is ok internally gets compared to the wrong
> setting and is reported as inconsistent through the Add command,
> however just executing Add again adds the file without complaints. I
> can reproduce the problem by using my directory of WOW addons (which
> range in about 233mb and 9000 files from diffferent sources, mac and
> windows), and I was able to add and commit all files eventually.
What I found out is that there is, as it appears to me, one bug in
this, not two, as I originally assumed.
The "Add" command is internally broken up into two parts:
1. Add the necessary information locally to make the file part of SVN control
2. Add the necessary properties from the auto-props settings in the
svn config file
If I add a lot of files and Add complains about one of those files
having inconsistent line endings, then the file has already been
added, it's just the svn:eol-style property that hasn't been added. If
I re-add, the file is thus no longer considered a candidate for the
Add command and that's why it doesn't complain on the second go. The
property, though, isn't set.
I originally thought this was a bug, and it might still be, depending
on how it is supposed to work.
Thus, the statement I made earlier, that it seems that line ending
styles "bleed over" from one file to the next is wrong.
Since the Add command is internally broken up into two separate
operations (at least) I would consider an "error during Add of a file"
to not having added the file in the first place, since to correct it I
need to use another operation (properties) to fix it. However, I don't
know how this is supposed to work (ie. it might be this is how it was
both designed and implemented) so I won't call this a bug, more of a
usability issue.
The second problem, that Commit first does an Add and swallows up the
problem altogether, is, IMO, a bug. Commit will stop on the file with
the inconsistent line endings, not report it to the user, and finalize
the commit, reporing that it was successfully committed up to a new
revision.
In other words, this is what Commit does for such a faulty file:
1. Add the file (this succeeds), part #1 of Add
2. Add the properties to the file (this fails, but is not reported to
the user in any way), part #2 of Add
3. Send the modifications and commit
4. Report successful commit operation
Since I'm committing files produced by and edited by Visual Studio,
which also during build-process (and indeed just opening the project
files) creates some directories that I don't want in SVN, I have a
python script that removed those unwanted things, and checked that I
had remembered to ensure the right file encoding, etc. I simply
rewrote this script to also check for unwanted line endings (for
existing files as well) and report anything amiss so I won't be
experiencing theses issues again.
When I get some time later this week I'll try to isolate wether it's
TSVN or just SVN that fails to report the problem so as to find the
right bug-page to report it on.
Thanks for the comments so far, the whole process has helped me
understand more about how (T)SVN works than I did before, and that can
never be a bad thing :)
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
Received on Sun Jun 17 13:51:34 2007