>>
>> 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
done.
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