----- Original Message -----
From: "Erik Huelsmann" <ehuels@gmail.com>
To: "Wayne J" <wayne@zk.com>
Cc: <users@subversion.tigris.org>
Sent: Monday, July 16, 2007 1:04 PM
Subject: Re: What does this error mean?
> 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.
>
Here's the error message that I got:
"Sending src\mw\src\mwin\makefile
Sending src\mw\src\mwin\winlib\makefile
Transmitting file data .svn: Commit failed (details follow):
svn: Can't open file 'C:\dev\src\dx_newdisp\src\mw\src\mwin\winlib\.svn\text
-base\makefile.svn-base': The system cannot find the file specified. "
I know that the files up to and including this file were committed. I don't
recall for sure if the files after were committed. I posted and email on the
list but no one responded to it. I had to clean things up and get on with my
work. I will try to carve out a little time to try and make this happen
again.
This has also been reported by another user. In this case the problem was
caused by inconsistent EOLs. In this case the user specifically states that
only part of the commit completed (up to and including the file with the
inconsistent EOL's) but the remaining files in the commit were not
committed. Please see http://svn.haxx.se/users/archive-2007-02/0246.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 16 23:40:25 2007