Re: [Monotone-devel] some (negative) feedback -- useful reading

[Nuno Lucas]

On 1/25/06, Nathaniel Smith <address@hidden> wrote:
>   -- apparently netsync incompatibilities are causing real users
>      problems.  Unfortunately we probably need to do one more
>      data-migration to switch cert formats, and I'd guess at least two
>      more netsync breaks (once to make it fast, once to sit down and
>      seriously clean it up and come up with a story for compatibility,
>      so we can have some confidence we'll be able to support it)

It's a real problem when you have a lot of users of your project. You
end having to support not only your project code but also teach
monotone and the "quirks" of it on every version change.

I understand that the project is not considered mature by it's
developers for production use, but it's just such a good project
that people will end using it anyway and then feel a bit disappointed
when migration problems occur.

>   -- monotone-dumb would be useful.  Since it wouldn't take much more
>      than a few days of python hacking to make it basically usable,
>      this seems doable if anyone wants to make it happen.  (I'm not
>      quite sure this

I think of this as an essential feature to have, because then you could
mail binary patches (that is, with all the history of multiple commits) or
sync between two databases without networking (remember not
everyone is connected to the Internet or has the bandwidth).

As a start, the ability to sync between two local databases would be
enough for me. Then one could just mail/save a second database
created just for that purpose, by syncing just specific branches(s).


There are other things I miss:

-- Working copy merges.
    When a merge fails I think it's much more clean to do it this way.
    It's not at commit time that one should fix a merge fail. One would
    merge on the working dir, re-compile, re-run all tests and only then
    commit again.
    I also think this should be the default behaviour (but I'm open to
    change my mind on this), with the option to not use the working dir.

-- Some commands shouldn't need a working directory.
    Commands like log shouldn't need a working directory. Specially
    important if you want to automate some tasks on a cron-job.
    I confess I don't recall any others right now, but I believe there
    are more.

-- Having a local revision ID selector.
    I liked mercury way of having a local revision ID. You need the full
    revision id to pass to others, but for local things a short local
    revision id is more natural (and you have the feel of the repository
    growing).
    I think this should not be too difficult to implement, as every sqlite
    table row has an implicit 64 bit integer id (used internally for the
    btree index, or explicitly if during table creation).
    As an advantage, for very large repositories, it should be faster to
    retrieve revision info for simple monotone tasks (no need to search
    for the full revision id).

-- Have a "shortlog".
    I use monotone locally to version changes to 3rd-party libraries I
    use in my code, so when a new version of that library get's out I
    commit it in my local db (so I can check the changes latter if I think
    I found a bug and/or different behaviour).
    This usually means a lot of changed files and "monotone log" is
    too noisy with all the changed files.
    Ideally, I would want a "monotone shortlog" which would just show
    a date, author, first log line and the revision (it could be just the first
    digits or the local id I talked above).
    That way I could easily fetch the right revision id and show more
    info on it, if I wanted.


Well, this are just my .02 €, keep up the good job :)


Best regards,
~Nuno Lucas