monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruce Stephens
Subject: [Monotone-devel] Re: user-friendly hash formats, redux
Date: Mon, 06 Dec 2004 22:21:50 +0000
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux)

Tim Woodall <address@hidden> writes:

> On Sun, 5 Dec 2004, graydon hoare wrote:

[...]

> I solved this as follows: every database had a unique ID. Monotone
> can't do this AFAICT because you can clone a database with cp. For
> my design whether you created the db with dcvs init or cloned an
> existing db with dcvs clone your new db would always get a unique ID
> (baring collisions reading 16 bytes from /dev/random)

I'd have thought it would be cleaner to give each branch a unique ID,
and then somehow associate human names with them.  That wouldn't help
human-visible conflicts between the same branch name in two databases,
but it would prevent problems underneath, so you'd need some way to
resolve such conflicts.

[...]

>>    - another local sequential system might involve keeping a sequence
>>      number for each author, sorted by date, such that the numbers go
>>
>>        "derek-10", "graydon-12", "matt-72", "joel-13", "derek-11"
>>
>>      (this would have an interesting social effect of automatically
>>       "ranking" contributors by commit volume, such that I would be
>>       committing "graydon-206", just after "njs-38". also the numbers
>>       would be quasi-stable and quasi-global for teams which shared
>>       complete history.)
>
> what would happen if you committed (two different) graydon-206 versions
> to two different repositories and then tried synching them?

Those are local names for revisions---they're generated from the
database, so they don't get synched.  (So one ends up as graydon-206
and one ends up as graydon-207; presumably both repositories would be
consistent in which was which, if the clocks of both computers are
synchronised.)

[...]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]