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

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?

---------------------------------------------------------------------
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 03:53:27 CEST