[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 23:46:47 CEST

----- Original Message -----
From: "Wayne J" <wayne@zk.com>
To: "Erik Huelsmann" <ehuels@gmail.com>
Cc: <users@subversion.tigris.org>
Sent: Monday, July 16, 2007 2:40 PM
Subject: Re: What does this error mean?

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

Actually after reading it again I see that this is a completely different
issue. I will try to find some time to investigate my problem further and
post the results

---------------------------------------------------------------------
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:46:23 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.