Okay, so it looks like what I've really found is an oddity with line
endings (see below).
kfogel@collab.net writes:
> "Perry E. Metzger" <perry@piermont.com> writes:
>> 2) I decided to kill the thing after about 20 minutes. After all,
>> that's what some user might do. kill -9 did the trick well.
>
> Okay. Probably you killed the client after the commit had already
> gone in (you don't say what repository acces method you were using).
No, it was in the middle of spewing .'s and giving me messages about
"transferring files". (I'm using svn+ssh, by the way...)
>> 3) The post commit script got called, and mail got sent out noting the
>> files that were updated in the (partial!) commit, with the "new
>> revision number", but without the commit message and with the
>> Subject: of the message missing. Really weird!
>
> What does it mean that the commit was "partial"? Were some things
> supposed to be committed that weren't?
>
> So far this looks like a hook mailer bug. Is there any evidence that
> the commit is actually incomplete in the repository?
I initially thought that the commit was not complete, but it appears
that it was. I've found a much less serious although annoying problem
-- the transactional behavior is not an issue.
I've found some other very weird behavior, which may explain why the
copy took so long AND why the repository grew a lot after it.
To give the full story:
1) Import some code on a windows machine, with the autoprops set to
make line endings native.
2) Check out the files on a unix box.
3) "svn cp localpath1 localpath2"
4) svn commit the copy.
This was taking a *very* long time, as I noted.
5) kill the commit.
Anyway, to determine if the commit had somehow not been complete, I
tried to check if the two branches were the same by doing an svn diff,
naively thinking that the two should be identical. When I saw lots of
spewage, much of it with "-" at the start of the line, I assumed I had
empty files or some similar corruption and reported the bug.
A manual check right now, however, reveals that this is not the
case. Checking the files locally after a fresh checkout shows the
files to be identical. What is happening to make the diff weird, you
ask?
Well, first, note that every line of every file is being marked by the
diff as being removed from the one file and then inserted nearly
identically into the other copy. I say "nearly identically" because the
difference is precisely the existence of ^Ms in one of the versions in
the diffs -- which I only noticed when looking at the diffs in emacs
after puzzling over them.
Now, subversion really shouldn't be noticing any of this, I would
assume, since:
$ svn pl -v Somefile.java
Properties on 'Somefile.java':
svn:keywords : Id
svn:eol-style : native
perry@alchemist$ cd otherbranchdir
perry@alchemist$ svn pl -v Somefile.java
Properties on 'Somefile.java':
svn:keywords : Id
svn:eol-style : native
...all the files are set eol-style native.
What I am guessing is happening is this, though I may be totally
wrong. I'm guessing that subversion imports the files in as "binary",
and treats eol-style as some sort of postprocessing it does during
checkout which has no impact on diffs in the server done for
deltification and other purposes. When I tried to do the svn cp +
svn commit locally, it noted the fact that every line was different
between the two versions and doubled the size of the test repository.
My guess is that if eol-style is set to "native", files should be
imported in some sort of canonicalized line ending style to prevent
this sort of thing from happening, though it isn't clear what to do if
you forget that when you import and change the eol-style
afterward. Anyway, it is highly unexpected behavior, and might cause
trouble with merges and other similar behavior later on -- it should
be fixed somehow. I can imagine merges and commits between different
platforms causing the repository copy to have all sorts of weird line
endings in different parts of the files if that's the case.
> You don't have a local copy of the repository :-), but you do have a
> working copy. If you run
>
> $ svn cleanup
>
> in there, does it fix these problems?
Seems to work perfectly. :)
> I doubt you committed a partial txn, but we'll need concrete details
> to know for sure.
You were right about that. The database wins again. At least I did
find something legitimately strange so I'm not entirely embarrassed by
my earlier report. :)
--
Perry E. Metzger perry@piermont.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 24 23:30:46 2004