Re: [Monotone-devel] Re: user-friendly hash formats, redux

[Zack Weinberg]

Nathaniel Smith <address@hidden> writes:

> On Tue, Dec 07, 2004 at 08:24:57PM +0100, Jerome Fisher wrote:
>> I'm not a fan of unstable revision IDs, though nobody seems to complain
>> about this in BitKeeper. BitKeeper uses unstable revision IDs and
>> stable, global, human-unfriendly keys. The user interface is so focused
>> on the former that users are often unaware of the latter (which can be a
>> bad thing). Note that the BitKeeper's revision IDs do tend to stabilise
>> over time, especially in the common case of having a central,
>> authoritative repository that people regularly sync with.
>
> BitKeeper is kind of different, though, isn't it?  Somewhat more like
> Arch, in that BK has "repositories" as first-class objects, and you
> can talk about them by name and stuff?
>
> Real questions, actually, I've never seen BK in action :-)

I don't know much about what BK is like *now*, but in 1999 it was the
case that repositories were much like Monotone repositories - not
special objects, just collections of files in directories.

At that time, also, BK had *no* concept of unmerged branches.  Any
given file could only have one head.  When you did a 'resync'
operation to bring in changes from someone else's repository, if there
were conflicting nodes on the graph, they got renamed and auto-merged.
The crucial difference from monotone is that this happened even if
there was a textual conflict.  Merge nodes that needed manual conflict
resolution were tagged as such, and you'd then go and perform a
'resolve' operation - which created brand new revisions on top of the
merge.  Imagine if CVS checked in the files with the conflict markers
in them, and then you were expected to fix up the files and commit
again.  (This would be catastrophic in CVS, of course, but in BK it's
okay if your local repository is briefly unbuildable.)

Not having any concept of unmerged branches makes life considerably
simpler in the guts of the implementation, but does make life harder
for users - you have to remember not to merge with repositories that
contain work that you don't want.  There was an ongoing project called
'lines of development' that was supposed to provide the usual
functionality of persistent unmerged branches (that could later be
merged by explicit user request) but it was always a month from being
done, all the time I worked at bitmover, and I am given to understand
that it is still not done today.  [Personally I blame this on Larry's
religious commitment to not breaking the SCCS file format.]

Anyway, the unstable user-visible revision IDs were never much of a
problem, that I recall.  (It helps that if you pull from someone and
immediately push back to them, then both of you will agree on all the
revision IDs.)  The stable, global, human-unfriendly keys, however,
were a continuing source of headaches - primarily because they were
not content-based and they kept turning out not to be unique enough.
I guess this has been sorted now, since otherwise the kernel folks
would be tripping over it alla time.

zw