On 7/16/07, Wayne J <wayne@zk.com> wrote:
>
> >>
> >> 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.
They have not been committed? That is when you check out the files
from the repository changes to file1.c and file2.c are there and those
of file3.c and file4.c are not, or do you mean that file3.c and
file4.c are not marked as committed in your *current* working copy.
This is a big difference, since with atomic commits, the former can't,
but the latter *can* happen.
> Here are the problems I see:
> a.) Subversion promises atomic commits. This commit is not atomic, half of
> it succeeds and half does not.
I've yet to find a situation where this occurs, repository side, so,
if you have a reproduction recipe, we want to know about it ASAP.
> 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've never seen this happen either, so, the same applies here too: if
you know how to achieve this, please tell us ASAP! Because I'm not
aware this can happen the way your description sounds to me.
> 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.
Yes, this is a known and documented - all be it somewhat cumbersome -
problem when using mixed case-sensitive/non-case-sensitive
environments.
> 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.
What I *think* you're seeing is that *updates* aren't atomic, but we
never guaranteed that. What we guarantee is that *if* a change is
accepted into the repository, it's accepted completely, or not at all.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 16 22:04:20 2007