On 7/16/07, Wayne J <wayne@zk.com> wrote:
> ----- Original Message -----
> From: "Ryan Schmidt" <subversion-2007b@ryandesign.com>
> To: "Rory Clark" <roryslists@clarkzoo.org>
> Cc: <users@subversion.tigris.org>
> Sent: Saturday, July 14, 2007 7:57 PM
> Subject: Re: What does this error mean?
>
>
> > On Jul 14, 2007, at 20:45, Rory Clark wrote:
> >
> >> And more importantly, how do I fix it?
> >>
> >> Error: Failed to add file 'D:\svnroot\Development\Some\File.cs': object
> >> of the same name is already scheduled for addition
> >> I'm getting this all over the place after a commit failed talking to the
> >> server.
> >
> > It sounds like your commit succeeded, but your working copy doesn't think
> > it did. Try checking out a new working copy. Verify that your changes did
> > indeed make it into the repository. Make sure you don't have any other
> > uncommitted or unversioned work in your old working copy. Then delete the
> > old working copy and use the new one.
> >
>
> 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.
>It seems that at least in some cases subversion (the client)
> decides that it a file is should not be committed because of a problem
> generates a commit error but commits the file anyway.
I'm sorry, but that's not how the Subversion commit process works.
This is how it *does* work:
- You issue a commit command pointing Subversion to a working copy
- Subversion finds the working copy and reads the administrative data
- From the admin data and the text bases, it determines which files
have changed and thus need committing
- It calculates the Repository Normal Form [with the right EOL style]
for each of the files it will be sending to the server
- It calculates the difference against the text base for each
item-to-be-committed
- It opens a connection to the server
- It describes to the server what the working copy looks like and
which items it wants to change
- It sends the actual changes to the server
- The server checks if the changes conflict with any changes already
in the repository
====> If no errors have occurred until here, the server accepts the
commit. The working copy is still in its original state. If the server
rejects the commit, the working copy stays that way.
- The server notifies the client of its success
- The client-server connection is terminated
- The client starts updating the working copy
If an error is encountered in the last step, the working copy isn't
completely in sync with the server, but the change has been accepted
in the repository.
Failures in the last phase should not happen, but aren't guaranteed
not to occur.
I hope this helps you understand the commit process. If you have any
remaining questions, I'd love to answer them.
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 19:45:45 2007