Handling unmergeable files -- a call to arms

[Russel Winder]

Stephen,

On Wed, 2009-06-03 at 11:59 +0900, Stephen J. Turnbull wrote:
> Russel Winder writes:
[ . . . ]
>  > I guess we have to get into nitty gritty details to argue this one --
>  > whilst fun, I am not sure it is crucially important.  The critical
>  > question is whether two repositories can diverge independently (which
>  > clearly then can since this is DVCS) and then be forced into consistency
>  > by outside agents -- I am not sure that this is the case for any DVCS.
>  > However my knowledge of Git is not sufficiently detailed to be
>  > confident.
> 
> Indeed, that is the critical question.  In the case of git,
> consistency is *always* forceable in the sense that both repositories
> contain the same content and history, up to renaming of branches,
> *without* losing any content, history, or branch heads.  *Objects
> (content, trees, commits, tag objects) have the same name in both
> repositories.*  (That's what I mean by "git is a distributed cache",
> YMMV.  If that's uncomfortable for you, I'm happy to change my
> terminology.)  I don't know how much of that is true for Bazaar or
> Mercurial; it's basically false for Darcs, and meaningless for CVS and
> Subversion.

Hummm... this clearly requires a lot more thought on my part.  If a Git
project really is an instance of a distributed database, then it is a
very different beast to the Bazaar and Mercurial analogues.  (I have
sort of struck Darcs, Monotone, Arch, Aegis, etc. off the list as being
unlikely to survive in the mainstream -- I hear even the Haskell people
(GHC at least) are looking to switch from Darcs to Git.)

It also leads to interesting legal issues regarding IP and licencing.
But that is way off-topic for this email list :-)

> So what we need to do here is define "consistency".  In the current
> context, clearly it's not "consistent" to have two heads purporting to
> be "current", but which contain differing revisions of "unmergeable"
> files.  Git is not consistent in that sense, but it does allow
> convenient (colocated) management of these "Doppleganger" revisions.
> 
> Note that in a merge no current VCS actually merges storage (it's
> arguable that formats like knits and weaves do that in a relevant
> sense, but I'm going to put that aside for now).  Rather, to merge in
> the working tree a new file is written and the old ones discarded.
> The main issue here then is how to choose from two (or more)
> unmergeable versions, or if there is some way to assist in merging
> them.

I definitely need to think about this more.

On the other hand, I can envisage creating a Bazaar plugin to solve the
original problem without solving these more general problems :-)

-- 
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel at russel.org.uk
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder at ekiga.net
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090603/3242cf1e/attachment.pgp