[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Is there ever a good reason to lock down the repo when performing a copy (no, right?)

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Fri, 15 Aug 2008 22:59:17 -0500

On Aug 15, 2008, at 22:04, Matt imMute Sickler wrote:

> On Aug 15, 2008, at 20:53, Matthew Russell wrote:
>> Hello - I'm having trouble finding something that definitively
>> says that svn copy works in such a way that you should never have
>> to lock down the repo during a large copy for fear of someone
>> committing during your copy and, thus, compromising the integrity
>> of the copy somehow by introducing a new revision.
>> I think the fear from our support folks might be two-fold: 1) that
>> the commit during the copy would somehow result in corruption, and
>> 2) that the commit would mix up revision numbers and the copy
>> would somehow end up being two different revisions.
>> It stands to reason that svn copy would work strictly on a
>> revision (even if you specify HEAD, which is still a specific
>> revision when svn copy is invoked), which would make the fact that
>> someone else is committing during the copy a moot point. It also
>> stands to reason that everything is handled by a transaction with
>> svn, so unless I'm wrong, that pretty much covers the issues, right?
>> Again - it's not me (no, really!) that needs convincing. It's just
>> that the lack of "it's ok to commit during an in-progress copy"
>> being written in stone somewhere has spooked people around here.
>> Any pointers on anything else that might be helpful to dispelling
>> this issue?
> `svn cp` normally operates on a Working Copy and doesn't interact
> with the server. now, assuming that you do a URL to URL copy (or
> even WC to URL), it is done as if you had checked out the whole
> repo, done the cp locally, then committed the changes - i.e. its
> still an atomic operation. yes there will be a "race condition":
> Person A - begins `svn cp $URL/trunk $URL/tags/foo-1.0`
> Person B - begins `svn ci` on a wc of /trunk.
> Person B - successfully commits
> Person A - svn cp completes. BUT its still a copy of what /trunk/
> was like when the operation was started. Person B's commit will
> not be included.

That's not a race condition.


"A race condition or race hazard is a flaw in a system or process
whereby the output and/or result of the process is unexpectedly and
critically dependent on the sequence or timing of other events."

Subversion has no flaw in this case. It behaves correctly, regardless
of any other commits happening while you're trying to do your commit.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-16 06:00:08 CEST

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.