Future bzr features: split file tracking and type-specific merging

[John Arbash Meinel]

Jan Hudec wrote:
> On Thu, Apr 27, 2006 at 14:17:30 -0500, Andrew Lambe wrote:
>> Are there any plans for bzr to support splitting of versioned files?
>> For instance, if I write a long bash script and later find that I want
>> to reuse a portion of it in another script, I would split code to reuse
>> into another file.
>> Currently with bzr I would now have a modified file with a bunch of
>> deleted code and an added file with the old code in it, but bzr has no
>> association between the two files or the code they contain.
>> >From what I understand GIT has features to support this kind of
>> tracking.
>> Will bzr?
> 
> I don't know anything about such plans, but if you could come up with
> a description what exactly it should do, someone may be interested enough to
> actually do it. Could you at least try to find out what the GIT feature is
> and describe what you would like to see in bzr so we can discuss pros and
> cons of doing it?

I don't know about git. I do know that subversion supports this sort of
thing. But subversion is the only one I know of that supports the "svn
copy" command. Which means create a copy of this file over there and
keep its history.

In my head, there are a few issues with it.
1) That is how they do renames. Which means renames are actually an
add+delete, just a history sensitive add.
2) That is how they do 'branching' by copying the whole tree somewhere else.
3) After copying a file, if you want to apply a patch, which file gets
the patch? Do both of them? Is it just the one that 'fits' the best. Do
you have to manually decide?

In my view (3) is one of the major reasons that SVN still doesn't have
nice multiple merging support. I could be way off base, but a tree could
be have copies of the same root-level file 100 times (and then modified
as needed), it would seem that a merge operation wouldn't know which
files correspond with which.

My understanding of Git's approach is that it *doesn't* track what file
came from what file. And it handles renames by saying, "You had a file
with sha hash X in path Y, and then another file showed up at Z with the
same hash X, you must have moved it". (And it does it at merge time, not
commit time).

> 
>> Second, are there any plans for bzr to support intelligent
>> type-specific merging, such as preserving functions in C code or tree
>> structures in XML?
> 
> Basically yes. Bzr is actually quite flexible, so when versioned properties
> go in (not in 0.8, but may be in 0.9 and certainly before 1.0) it will be
> mostly a matter of actually providing the diff and merge alorithms.

We have per-revision properties now. But yes, we need to add
per-inventory-item properties. There is still some discussion about how
to do that in the best way. (One of the issues being how to
appropriately handle resolving conflicts).

> 
>> The best way to do this for each of a multitude of languages, file
>> formats, and syntaxes is of course a much broader topic and feat than
>> bzr is going for (right now ;), but bzr could support the infrastructure
>> needed.
>> There are essentially two parts to this: language/file format detection
>> and type-specific merging.
>> For the first part, plugins could aid the user in detecting or
>> specifying the file type to bzr, but is bzr being designed to allow
>> arbitrary file type metadata to be kept about each versioned file?
> 
> Not yet, but is planned -- properties mentioned above.
> Note, that these will not be arbitrary in the sense they are in subversion --
> a plugin will have to define semantics for each property -- but that's what
> you need here.
> 
>> For the second part, is bzr being designed to allow different merging
>> behavior (supported by plugins) based on those file types?
> 
> It actually already does, though only by command-line options. There are
> weave-merge and 3way-merge algorithms and calling external merge tool is
> expected some time in near future.
> 

All true. :)

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060427/2b8744a9/attachment.pgp