Re: [Monotone-devel] Re: Few remarks

[Jérôme Marant]

Quoting Bruce Stephens <address@hidden>:

> Jérôme Marant <address@hidden> writes:
>
> [...]
>
> > This is connected to files being identified by their full
> > path, so when adding a new file in some directory, you need
> > to "monotone add" it from the top directory of the tree if
> > you want it to have a correct location in the database.
> >
> > How about doing the following:
> >
> > Whenever a new directory is created, create a MT directory inside
> > providing the proper database name. An additional "level" parameter
> > would provide the path from the top directory.
>
> That would be one way.  Alternatively some monotone commands could
> search parent directories to find the relevant MT directory.  That
> feels cleaner to me (and is what other systems do, I think).  I seem
> to remember there being a branch which did that?

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.

> [...]
>
> > Using hashes as revision IDs is definitely not user friendly.
> > I know, it has already been mentioned in the FAQ, but even
> > a simple ancestry graph can show that it is not really
> > "human readable".
> > IMHO, a simple database-wide per-commit autoincremented integer
> > would be much nicer. It is even natural when using database,
> > AFAIK and SQLite does this.
>
> monotone is a distributed system, so I don't see how that would work.
> Unless the integer is local to each database (but the hash is used
> internally in certs and things).  That might be a useful convenience.
> I'm not sure---it might be worth someone trying.

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.

Cheers,

--
Jérôme Marant