> Subversion needs to amend its data model to provide copy-to
> information, to complement the current copy-from information.
> This is easier said than done. It implies repository format changes.
> We'd need to a way to modify old revisions to store this information
> because the copy-to data needs to sit at the copy *source*.
Huh ... this part I don't get. Surely the copy-to information would
live in the same revision where the copy (or rename) actually happens,
right? That does not require rewriting old data.
I understand that this does not offer an efficient way to get _all_ the
places a node has been copied to, but in the case you're talking about,
we only care about the rename target. If the wc can enforce that both
sides of a rename be committed at the same time, the copy-to will
always be in the same revision as the delete.
Or, to put it another way, if the copy + delete are in separate
revisions ... then for tree conflict purposes, we can assume that the
delete is just a delete.
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2010-01-05 21:19:04 CET