Use Case for Path Tokens

Robert Collins robertc at robertcollins.net
Fri Aug 22 02:24:57 BST 2008


On Wed, 2008-08-20 at 20:49 +0200, Martin von Gagern wrote:
> Hello!
> 
> I think I have an interesting use case for the Path Tokens specification 
>   from http://bazaar-vcs.org/DraftSpecs/PathTokens.
> 
> The general theme is that of a branch derived from a released tarball, 
> and a different branch which is a clone of the offifial development 
> trunk. While merging the tips of these two would simply be expressed as 
> joining all the files with common paths into one, this approach might 
> lose rename/move/copy/join operations performed in these branches since 
> the time when they diverged, and would probably cause conflicts for 
> every file changed in either branch, for lack of a common ancestor.

It would not lose anything, as a token join is a first class operation.
Conflicts would not occur where the content was the same, and where it
wasn't the same, then you would expect a conflict :).

> Afterwards, the merges should propagate changes from both branches to 
> the newly linked files. In the end, the changes from both branches 
> should be present in the common branch, in a sensible way that allows 
> further merges from either branch.

That is the point of path tokens :P.

> For every pair a and b of files with a common ancestor c, after the 
> merge a should contain all changes applied to b since c, and b should 
> contain all changes applied to a since then. This sounds a lot like a 
> normal content merge, but due to the fact that here every file can be 
> part of more than one pair, this means changes from possibly more than 
> one line of modifications even during a single merge.

I think this is a confusing way of expressing what is intended. ancestor
is conflated with token changes and branch histories.

Note that we already have a 'join' command. I must say though, i still
don't understand whats unique about this use case vs the standard
parallel import use case.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080822/aced4ab1/attachment.pgp 


More information about the bazaar mailing list