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

RE: Fixing issue #842

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-02 23:44:30 CEST

> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> A reminder of the bug:
>
> Given a repos directory A and child node A/foo:
> - copy A/foo A/foo2; commit
> - copy A A2; commit
> - vi A2/foo A2/foo2; commit
>
> The bug manifests itself in an error about two nodes trying to
> acquire the same new node revision ID. The root cause, though, is
> that filesystem is trying to treat A2/foo and A2/foo2 as being on
> the same branch, despite the fact that they are not. 'A/foo' and
> 'A/foo2' were on different branches, then we branched their parent
> directory 'A', so 'A2/foo' and 'A2/foo2' should also be on
> different branches.
>
> After chatting with Bitt Tutt about this bug, I've set out to code the
> solution:

Been helping Ben out with his alliteration recently, Mike? :)

>
> Instead of copied subtree nodes blindly assuming the Copy Id of
> their parents, some determination about whether or not that node is
> on the same branch as the parent must happen. If the child is on
> the same branch as the parent, it assumes the parent's Copy Id;
> else, a new Copy Id is generated for it.
>
> An implementation question lingers:
>
> In generating this new Copy Id for the branched branched child
> node, should that Copy Id look like a first-class COPY or not.
> That is, should the question svn_fs_copied_from () on that node
> reply that yes, that node was copied though no svn_fs_copy()
> operation actually occured as part of that revision? Or, should we
> populate the new row in the `copies' table with some magic that
> means "This wasn't a real copy, just a new ID handed out to a
> branch of a branch"?
>

Good point. This new CopyID is a lazily instantiated copy. We knew the
user meant to have us do this earlier, but since Subversion is so lazy
it finally got around to doing it now.

So there a couple of points in this issue:
* What should the new CopyID's source information be when A2/foo2 gets
modified?

This should be A/foo2 and the TxnID of the A/foo -> A/foo2 copy
operation.

* What should we do about the list of copies in a transaction?
Well, clearly, we should add this copy to that list.

* Should we somehow distinguish in the Copy table &/or the transaction
changes information that this was a lazily invoked operation?
Yes, we should certainly do that. We don't want svn's dump/load code
getting confused.

* Should we display this new distinction in transaction change output
from svn log?
I would tend to say not. The user won't notice any visible difference.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 23:45:00 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.