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

[Oren Ben-Kiki]

On Friday 10 December 2004 03:18, Brian P. Campbell wrote:
> Once you start talking about branch.author.seq#, you
> might as well just use the selectors that are already built in. I
> think the current set of selectors could be enhanced a little. For
> instance, various people have discussed adding +n or -n for walking
> up and down the tree, which I think is a great idea.

The +n/-n notation has a problem when there's a fork (or merge).

> Also, it would 
> be nice if there were some really easy way of adding a tag to a
> revision as you were checking it in.

Tags are in principle enough to solve all(most) all the revision ids 
issues, with just one caveat - they require the author to do all the 
work by himself.

Hmmm. Perhaps the right way to go about this would be to create an 
"automatic tagging utility", completely separate from the core Monotone 
program itself. This would allow experimenting with all kind of 
automatic "local ids" schemes (maybe even allow more than one to be 
tried at once for the same db, assuming each scheme used a distinct 
one-char prefix for its tags). If some scheme ever becomes widely 
recoghnized as "the" way to do it, it would be a candidate for 
integration into monotone itself.

For this to work, it is necessary to be able to retract a tag from a 
revision (for "renumbering"). Is this possible today? There's no 
--untag command... I suppose that being able to retract any cert could 
cause problems, but the restricted case of tags makes more sense.

> Finally, I think the default date
> format should be changed. "T" just isn't a good delimiter; I can't
> immediately scan it and see the separation between date and time. I
> realize that that is an ISO standard, but I don't think it's a very
> good one. Using just a space would make it much easier to read, but
> really any standard delimiter character would work better than a "T".

My favorite character here is be '+': 2004-12-10+13:12:45. It makes 
perfect sense if you think about the date-only part as specifying the 
base time of 00:00:00; you then have to add the time part to get to the 
full timestamp value. It is a real pity that time zone deltas have the 
wrong sign, otherwise timestamps would have been a simple expression 
resulting in the UTC. As it is, if you write 2004-12-10+13:12:45+02:00, 
the UTC is actually 2004-12-10+11:12:45 rather then the expected 
2004-12-10+15:12:45. I never could figure out why the sign of the time 
zone is reversed. I guess the whole mess seemed like a good idea at the 
time...

At any rate, in YAML we recommend programs support both the strict ISO 
compliant T/t format and also a more relaxed space separated version 
for maximal readability. If the ISO had gone with using '+' instead of 
T/t we probably wouldn't have included the space version; as it is, we 
decided not to go with '+' because space is much more readable (compare 
2004-12-10:13:12:45+02:00 with 2004-12-10 13:12:45 +02).

Have fun,

 Oren Ben-Kiki