On Tue, Sep 15, 2009 at 01:30:07PM +0200, Stein Somers wrote:
> I didn't want to hijack a thread for something that isn't important to me,
> but now I'm intrigued.
>
> Suppose I want to have a moving tag e.g. /tags/stable (call it the_tag)
> which can "point to" various revisions e.g. in /trunk (call it the_revision).
> You can always move the tag by first deleting the_tag and recreating it as a
> copy of a new revision, in two transactions.
>
> But in the thread "Move from CVSNT to SVN?", Lorenz writes:
> > svnmucc rm the_tag cp revision the_revision the_tag
>
> Indeed a neat way to do it a single transaction. The result is a single
> changeset in which the directory the_tag is replaced by a copy of
> the_revision. Or I suppose you could bundle multiple replacements in a single
> transaction.
>
> But in the thread "back-end fsfs DB corruption? - attempt to merge uncovering
> it", Stefan Sperling writes:
>
> > [...] if a file was replaced within a single revision
> > (which can also happen for directories under certain circumstances,
> > but which is actually not supported by design in 1.6.x).
>
> So should we shy away from retagging in a single transaction?
If you are only tagging and don't ever try to merge directory
replacements between branches, there is no reason to worry.
With merging it's a bit tricky.
It happens to work most of the time. But more by dumb luck than by design.
E.g. the working copy code in 1.6.x does not really represent replacements
in a way that allows it to deal with them properly in all situations.
Also, the client<->server communication has no proper representation
of a replace operation. The 'R' you see when the client is printing
information during a merge is fake -- the client received both a delete
and an add from the server for the same path, so it infers that there
was a replacement. But the server has no notion of it.
One known example where this causes problems:
Try merging a directory replacement from one branch to another and then
also delete items inside the replaced directory tree, and commit
the result. With 1.5.x, you can commit the replacement. With 1.6.0 to
1.6.5, you probably won't be able to commit the replacement, depending
on which repository access method (file://, svn://, http:// over neon,
http:// over serf) you are using; this is a bug which will be fixed
in 1.6.6. But in any of these versions, and in 1.6.6, post-replace
deletions won't be committed. See here for details:
http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_client/commit_util.c?r1=38927&r2=38926&pathrev=38927
There might be more problems with replacements in 1.5.x and 1.6.x
we aren't yet aware of. It will get much better once the spaghetti
code that is the 1.6.x working copy implementation has been cleaned up.
Then we can start to fix these problems properly.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394998
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 13:59:19 CEST