[rfc] what is 'merge tracking' means?

[Jan Hudec]

On Tue, Jun 27, 2006 at 08:19:44 -0500, John A Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alexander Belchenko wrote:
> > My friend ask me recently is bzr has 'merge tracking'? He use svn and
> > this term appear from their roadmap
> > (http://subversion.tigris.org/roadmap.html). I say that bzr is
> > decentralised version control system, so with merge is all right (only
> > cherrypicking is not implemented). But my friend cannot describe in
> > simple words what is 'merge tracking', so I'd like to hear from our wise
> > men what this term should means and is bzr has this thing?

I'll try to explain in detail:

When you want to merge more branches, it is necessary to identify, what
changes were made on each branch that did not yet made it to the other one
and combine these changes.

Merge tracking means the version control system keeps enough information to
be able to identify the changes itself. Bzr, as well as all other distributed
vcs do it. Subversion doesn't -- you have to tell it the last common revision
(previous merge or branchpoint) manually.

As for the cherry-picking, it means you manually select just part of the
changes from one branch to apply to another. Tracking cherry-picks than means
the tool can properly avoid re-applying them in following merges. So far only
GNU Arch/Bazaar 1.x to some extent (keeps track of them, but the interaction
with full merge is a bit weird) and maybe Codeville (it uses a merge
algorithm that can do it, but I don't know whether it's actually implemented)
can do it. Also Darcs allows some kind of cherry-picking, but only for
non-overlaping changes.

> Merge tracking is something that all distributed vcs do fairly well.
> Mostly because they have to. While a centralized system can claim merges
> aren't all that common, decentralized systems do it as their basic work
> flow.
> 
> In SVN if you have 2 branches and you merge the changes between them,
> svn doesn't record that it was a merge. Just that you updated the
> working tree with some changes. (Which happen to match what was done on
> another tree).

Actually even CVS is smarter than Subversion, because it can at least merge
from the branchpoint, while in subversion you have to tell it even that
manually.

> SVK is layered on top of SVN, and since it is decentralized, it uses
> special revision properties to record merges.
> Obviously since SVK is possible, SVN *could* be tracking merges. But the
> developers didn't feel it was a high priority. Which is unfortunate,
> because without good merge tracking, branching is a real PITA. And
> integration branches are just horrible.

While SVK works quite well, Subversion model is really poor fit for
a massively distributed setup. It leads to complex mirror setups and a lot of
data duplication, because mirrors can't share the data even when they are
actually the same. Also it makes the repository structure rigid and harder to
drop old data when no longer needed.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060627/bb81c0b1/attachment.pgp