Re: [Monotone-devel] My impressions of monotone

[Nathaniel Smith]

I'm sorry, I completely managed to miss this email too, somehow.
Guess things are a little better now than back in August...

(If you no longer care about monotone, of course, then I hope everyone
else on the list will take my questions as being directed at them too
:-).)

On Fri, Aug 06, 2004 at 03:30:02PM +0300, Tommi Virtanen wrote:
> - monotone is missing an equivalent of "bk superset", a single command 
> that tells you whether it is safe to rm -rf things, without losing any 
> work. For monotone, this'd probably be separate for db's and workdirs.

Interesting idea.  I'm not quite sure how useful it is in monotone's
case, though, because of some other architectural differences:
  -- for databases, you can just run a "push" to be sure; this is
     always safe and painless (it never requires any merging, unlike,
     IIUC, BK).
  -- for working directories, you can just run "diff" or "status" to
     see if there are any local changes.

These pre-existing commands seem to handle the "bk superset" use case
pretty naturally, I think?

> - annotate/svn blame/bk annotate equivalent?

Yep, it'd be nice.  On the todo; I keep suggesting it would be a nice
project for someone, but no-one's taken me up on it yet...

> - I want a way to list all tags (in a brach)

'ls tags', though there's currently no way to restrict it to a branch.

> - list manifest/file hashes matching a selector

Agreed.  Stuck this in the newly cleaned up bug tracker:
https://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=12041

> - for moving things between db's, I'd like to see something like "bk 
> changes -L" and "bk changes -R"; that is, "if I pull/push now, what will 
> be transferred".

Hmm, interesting.  The code change for this would be a bit complex; do
you have any use case in mind in particular?

(Remember again that, unlike BK IIUC, "push" and "pull" in monotone
are completely safe and completely separate from merging.)

> - I want a way to list certs with name X (and maybe value Y). Right now 
> the ways to access them from the commandline seem quite limited, without 
> doing SQL.

Agreed.  I'm not sure what a good interface for this would be, though.
Any thoughts?

> - I want an equivalent of "bk changes -k -r+", that is, give the id that 
> describes the head of this branch. Currently it seems doing some text 
> manipulation on monotone status output works, but it's a kludge.

Honestly, the easiest way to do this right now is "cat MT/revision"
:-).  While this is impure and all, it sort of lowers the urgency of
such a thing...

Perhaps the new "automate" interface should contain basic revision
parsing commands?

> - I want a way to merge two _specific_ heads together, even if there are 
> currently >2 heads open. This is mostly so I can import the bitkeeper 
> history exactly.

We have this now: explicit_merge.

> - I tried to do the above with a temporary db where I'd transfer every 
> change from the initial branch creation to the latest id's on the two 
> heads I wanted to merge; then merge there and push changes back to main 
> db. I couldn't figure out a nice way to do that, and while playing with 
> mdelta managed to break some invariants in monotone. If this is a new 
> bug, I can give you more information.

If you still have the information, I'm curious; though things have
changed enough it may not still apply...

> - I want a way to merge things so I can review the merge before it is 
> "final". Should I do this with a temporary db, or is there another way?

merge-into-working-directory is a TODO item; that will give you what
you want.

For most people, it seems more common to just do the merge, and then
if there are any problems with it commit a fixup revision as a child,
before sync'ing.  With some strategic use of when you choose to sync,
you can get the effect of a temporary database -- before running a
merge, push your changes out.  Now, until your next commit/merge,
you can treat your main database as a temporary database, it contains
nothing irreplaceable.  Run your merge, and make sure things look good
before pushing them out.  If they don't look good, and you want to
just scratch that whole merge altogether, then just delete your
database and re-fetch from the server.

> All in all, thank you for a nice-looking version control system, if I 
> can manage to import my bk things, I'll say byebye to the bitkeeper 
> license and help you improve it.

Thanks for you feedback and kind words!  Hope we haven't scared you
off by misplacing your message...

> PS. The mailing list web interface gives 404s when you try to download 
> as mailbox.

Hmm, odd.  I've filed a report with the savannah admins about it.

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho