[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What does this error mean?

From: Wayne J <wayne_at_zk.com>
Date: 2007-07-16 20:56:48 CEST

>> Yes, this is probably what happens. I believe that this is a semi-serious
>> subversion bug.
> I don't really like the implications of the paragraph above. So, I
> propose we take a deep breath and study the facts before calling each
> other names.

Maybe I didn't explain the problem effectively.

1. I add/change files file1.c, file2.c, file3.c and file4.c

2. I do a commit of the changes. The check-in fails because file2.c has a
problem with it. However, file1.c and file2.c (the one with the problem)
*have* been committed but file3.c and file4.c have not.

Here are the problems I see:
a.) Subversion promises atomic commits. This commit is not atomic, half of
it succeeds and half does not.

b.) Even if atomic commits are not guaranteed I have a problem with
subversion telling me "I can't add your changes for file3.c and file4.c
because file2.c doesn't look right. And by the way I have committed the file
I think is wrong."

I have seen reports of this happening when subversion detects EOL
inconsistencies. I have personally run into this problem when a file was
renamed on Linux to change it case and svn has a problem with the
inconsistency of case on Windows.

I am perfectly fine with svn failing in both case I but I expect commits to
be atomic. If an error occurs the commit should be rolled back not left half

If I can't have atomic commits I would at least expect subversion to quite
on the bad file and *not* the good file following the bad file.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 16 20:56:29 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.