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

[Thomas Haas]

Zbynek Winkler wrote:
> Bruce Stephens wrote:
> 
>> You might want something that reflected history or structure.  For
>> example, if you had a branch foo, you might want the first revision to
>> be called foo.0, then foo.1, etc., with some way to handle forks and
>> things.  Of course that kind of naming might change as you sync with
>> other repositories, and it's certainly a local rather than global
>> naming, but it might still be useful.
>>  
>>
> It's been a while since I was thinking about this but the solution that
> I would be probably happy with would be a generation number (within a
> branch). That would be a global identifier that would sometimes select a
> group of things but that could be handled by appending part of the hash.
> 
> I'd like to point out that I still think that the full hashes should be
> the "main" identifiers. The generation numbers would just be an UI
> thing. The revision could then be identified by i.e. 'branch-53-ab'
> which would be a 53rd generation in 'branch', hash starting with 'ab'.
> 
> Since the branch factor tends to be relatively small it could be 'global
> enough' for common day-to-day use.
> 
> Zbynek
> 

Somehow I like the idea. However, the aliases get "long" again and
potentially use too much screen estate, especially when considering the
fact that branches often consist of Internet domain names.

Semantics in version automatically created revision identifiers usually
break on merging (see CVS horrible revision numbers). That's why I like
the revision ids in subversion: easy to read, remember, match, and
compare and a simple, intuitive semantic: ordering of commits in time.

Due to the distributed nature and local scope of incremental revision
numbers in monotone, the semantic would be ordering of commit, sync, and
pull operations in time. I believe this semantic would also be intuitive
and very easy to understand.


Regards
- tom