[Monotone-devel] Re: Few remarks

[graydon hoare]

Jérôme Marant wrote:

> This solution implies that you are absolutely sure the parent
> directory where you will find the MT directory is the one you
> are looking for. As far as I know, you can run "monotone add"
> everywhere in the tree and this automatically creates a MT
> directory.

that's a bug. monotone will (eventually, when we merge the restriction 
branch) ascend in the working copy until it finds an MT/ directory.

> When working locally, such an integer in unique. So, while keeping
> the hash for obvious reasons, an integer "alias" associated with
> the hash in order to make things more userfriendly would be nice.

such integers would not be particularly stable, as your database can 
acquire revisions "in the past" retroactively when you sync with others.

one stable numbering scheme which posesses the property you want (N+K is 
a child of N) would be to number the immediate children of *each* 
revision by the order they arrive in your database: consider the "first" 
child of N as N+1, and use a .fork.seq format for the remaining children 
a la CVS.

  first child: N+1
  second child: N.1.1
  third child: N.2.1
  ...

I guess that would probably make the UI a fair bit friendlier; it's been 
hard to nail down this concept before revisions existed, but now that 
it's a strict DAG I can see that it'd probably work. you'd chew up a 
little bit of database space with this, but I'm not opposed to 
implementing it.

(the algorithm for assigning numbers would be slightly trickier than 
this due to the fact that merges occur without a discriminated "trunk", 
so you would want to do something like "pick the shortest legal number" 
-- merge(2.4, 5.5.6) -> 2.5 not 5.6.8 -- to prevent version numbers 
expanding without bound.. but it's probably doable)

-graydon