[Top][All Lists]
[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.)
[...]
- [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/04
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Christof Petig, 2004/12/06
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Derek Scherger, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, John S. Yates, Jr., 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Tim Woodall, 2004/12/06
- [Monotone-devel] Re: user-friendly hash formats, redux,
Bruce Stephens <=
- [Monotone-devel] unique repository ids, Nathan Myers, 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09