|
From: | Jerome Fisher |
Subject: | Re: [Monotone-devel] Re: user-friendly hash formats, redux |
Date: | Tue, 07 Dec 2004 20:24:57 +0100 |
User-agent: | Mozilla Thunderbird 0.9 (Windows/20041103) |
Oren Ben-Kiki wrote:
There *is* a way for having stable, readable, consistent distributedrevision ids, by using CVS-like fork numbers and using the author's name as the fork's id:/-> 4.bruce.1 -> 4.bruce.2 (fork by bruce) / 1 -> 2 -> 3 -> 4 -> 5 (main trunk) |\ | \-> 3.richard-1.1 -> 3.richard-1.2 (fork by richard) \ \-> 3.richard-2.1 (another fork by richard) (This is all within a single branch, of course.)
Hmm. Am I missing something, or are you ignoring the case where a single author has multiple databases (which may well be differ greatly from one another)? It seems to me that gets back to the problem of rearranging conflicting fork IDs when netsyncing a single author's databases. 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. I'm a little surprised that nobody has brought up tags in this discussion; perhaps they don't work well enough in monotone yet (how are conflicts handled?). Regards, Jerome
[Prev in Thread] | Current Thread | [Next in Thread] |