Re: [Monotone-devel] Proposal for human readable revision IDs

[Steven Grimm]

Here's another approach that might be simpler. If each database has a 
unique name (unique within a set of databases on the same project, 
anyway), then you can use a serial number that's local to that database 
and it'll be guaranteed unique. For example:

User A creates a database and calls it "master"
User B creates a database and calls it "devel"

Now user A commits a change. The change gets a globally unique ID 
internally, of course, but is also tagged as "master-1". User B's first 
change is tagged "devel-1". Each database maintains its own sequence 
number and since the tags include a database name, there is no 
expectation that the numbers are unique between databases.

When the master and devel databases are synchronized, monotone checks 
for database name conflicts -- is this database or one of its peers 
using a name I know about, but with a different ID? -- and won't permit 
the synchronization to succeed if there are any. There ought to be a 
command to validate that a given name isn't already taken, so that 
people can avoid conflicts.

In theory, this could get ugly if 50 people all choose to name their 
databases "bugfix" or something like that. In reality, a new developer 
will start off by syncing with an existing database, and the duplicate 
names would be caught at that point, before the developer in question 
ever started doing any work. And of course projects can encourage or 
even enforce naming conventions (database names must contain your email 
address, etc.)

I agree with the original writer of this thread that the hex revision 
codes are too unwieldy to expose to humans on a regular basis. They need 
to exist under the covers, of course, and they can still be considered 
the definitive revision IDs, but I don't want to ever *have* to deal 
with one during my day-to-day work.

-Steve