You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jim Garrison <ji...@troux.com> on 2011/09/27 16:54:49 UTC
svn mkdir --> Conflict - what can cause this?
We have an automatic (Hudson) build that runs every night. It starts by making a tag directory into which it will then copy the current build root folder. Last night, the mkdir failed:
svn --username [obfuscated] --password [obfuscated] --no-auth-cache mkdir --parents http://svn/repos/troux/autobuild/trunk/20110926_233057 -m"create autobuild tag directory"
svn: Conflict at '/autobuild/trunk/20110926_233057'
The job was rerun this morning without making any changes and it had no problem with the mkdir. I can guarantee that the directory didn't exist in the repository prior to the mkdir command.
The svn server is running on Linux (Fedora 14) and is at version 1.6.16
The client is on Linux (Fedora 14) and is at version 1.6.17
Ideas?
Re: svn mkdir --> Conflict - what can cause this?
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 27, 2011 at 10:54 AM, Jim Garrison <ji...@troux.com> wrote:
> We have an automatic (Hudson) build that runs every night. It starts by making a tag directory into which it will then copy the current build root folder. Last night, the mkdir failed:
>
> svn --username [obfuscated] --password [obfuscated] --no-auth-cache mkdir --parents http://svn/repos/troux/autobuild/trunk/20110926_233057 -m"create autobuild tag directory"
>
> svn: Conflict at '/autobuild/trunk/20110926_233057'
>
> The job was rerun this morning without making any changes and it had no problem with the mkdir. I can guarantee that the directory didn't exist in the repository prior to the mkdir command.
>
> The svn server is running on Linux (Fedora 14) and is at version 1.6.16
> The client is on Linux (Fedora 14) and is at version 1.6.17
It can happen if any change is committed beneath the autobuild
directory in the short window from which the code retrieves its
version and then commits the next transaction. It is real easy to see
this problem if you are using mirrors and the write-thru proxy
feature. On a single server, it seems like it would just require
perfect bad-timing.
If your logs give you a timestamp when the command failed, you ought
to be able to run svn log and see if there was another commit at the
same time.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/