On Tue, Sep 27, 2011 at 11:05 AM, Jan Keirse <jan.keirse_at_tvh.be> wrote:
> Stephen Butler <sbutler_at_elego.de> schreef op 27/09/2011 10:58:26:
>
>>
>> On Sep 27, 2011, at 9:20 , Jan
>> wrote:
>>
>> > Hello,
>> >
>> > I've got 2 batch processes, one compile CHUI files and another
> compiling
>> > WIN32 files. They use the same working copy and update the working
> copy
>> > before starting.
>> > I wonder if this is safe: if the 2 update commands run at the same
> time,
>> > will this cause issues? So far it appears to work just fine, but I'd
>> > rather be sure than sorry.
>> >
>> >
>> > ps.: Both compilers run on the same machine and just invoke svn.exe
>> > --non-interactive --accept theirs-full --depth infinity update
>> > c:\workingcopyname, so there won't be a problem with incompatible
> clients,
>> > the client is the same. I just wonder if I could have problems with a
>> > locked working copy or something like that. The working copy is only
> used
>> > for compiling, there are never any changes in the working copy. SVN
> Server
>> > & Client: 1.6.17, OS WIN32, server = Apache.
>>
>>
>> Subversion operations that modify the working copy, such as update, use
>> a Subversion-internal "administrative" locking to ensure that the
> operations
>> don't collide.
>
> Great.
>
>> It's possible that build process B runs an update while build proces A
> is
>> already compiling. Then the effective source code of build A might
>> include files from different revisions, which is difficult to reproduce.
>
> I am aware of this risk but it won't cause problems in our setup: If this
> happened a second compile would be triggered automatically.
> I was only worried the working copy could get corrupted causing the update
> to fail, but if subversion handles this I should be safe.
It won't get corrupted, because of the internal locking that Stephen
mentioned. But the second update, being blocked by the "lock" of the
first one, will error out. So your build scripts should be prepared to
handle that (even if only by exiting with a sensible error message or
something like that).
--
Johan
Received on 2011-09-27 11:18:36 CEST