monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: multiple heads...


From: Emile Snyder
Subject: [Monotone-devel] Re: multiple heads...
Date: Fri, 03 Mar 2006 13:32:00 -0800

On Fri, 2006-03-03 at 20:56 +0100, Tim Ansell wrote:
> Okay there are two "types" of people I think the monotone people
> forgot. 
> 
> a) The read-only pull user.
> 
> This is the user which Holger pointed out, they just want to pull data
> and always get a good version. They possibly want a choice between
> "stable" and "bleeding edge" but it is unlikely. To them the SCM is an
> overcomplicated way to just rsync.
> 
> b) The commit little user.
> 
> This is the user which only has a small amount of time and might only be
> looking after or developing two or three "files" in the repository. They
> go for large amounts of time without touching the repository and don't
> ultimately care about the other files in the repository.
> 
> ------------------------------------------------------------
> 
> Nobody ever wants to see this,
> 
> > address@hidden ~/dev $ mtn -d tmp.db -b testbranch co tmp2 
> > monotone: misuse: branch testbranch has multiple heads

Agreed.

> First, as you mentioned the user has not misused the tool in anyway.
> You are blaming the user for something they haven't got any control
> over.
> 
> Second I have selected to checkout, I don't care that there are
>  multiple heads I just want, the latest, the best, version. I just want
> "what he has".

Yes, but this can be a somewhat subtle question.  Consider the following
graph of revisions (where the number represents the date that a revision
was committed.)

     1->2->3->4
      \
       +---------5

This might occur, for instance, when the dev that committed 5 had not
pulled and updated in awhile, so when they create and commit 5, the most
recent revision they know about is 1.  If you are checking out given the
above graph, --latest would give you revision 5; it's the most recently
committed.  But arguably the "best" or "most up to date" is revision 4.
Should --latest mean "the head with the longest path to the diverance
point"?  (Perhaps naming the flag something less time oriented?)

> Either the tool should do something like this
> 
> address@hidden ~/dev $ mtn -d tmp.db -b testbranch co tmp2
> Currently the repository you are checking out has multiple heads,
> Would you like to:
> a) Checkout the latest head
> b) Choose which head to check out
> c) Abort 
> ->
> 
> or if you don't like being interactive.

I don't have particularly strong feelings one way or the other, but
going interactive would be a fairly large change, while...

> 
> address@hidden ~/dev $ mtn -d tmp.db -b testbranch co tmp2
> Currently the repository you are checking out has multiple heads,
> 
> To checkout the latest head use the following command,
> mtn -d tmp.db -b testbranch co --latest tmp2
> 
> To make a choice between heads run
> mtn -d tmp.db -b testbranch findheads tmp2
> and then
> mtn -d tmp.db -b testbranch --choose <revision> tmp2
> address@hidden ~/dev $

Yes, except that it should just list the revisions for you to start
with, rather than making you run another command to find them.

> Something similar should also happen on an update.

Update works this way (in mainbranch anyway, not sure about 0.25)
already (with the exception of not having the --latest flag).

So just to be sure I'm hearing you right; is it sufficient for monotone
to have a --latest (or something) flag that attempts to (somewhat
intelligently) pick the best head in a multi-headed branch for
operations that need it?  (And to point the user to that flag when the
branch is multi-headed and they don't use it.)

> Just because you are a command line tool doesn't mean you have to output
> cryptic text messages. Be verbose and interactive! (Provide switches
> turn of the verbose and interactivity so it can be used by tools of
> course). Pretend the person just wants to code and doesn't care about
> the SCM or even other people.

Believe it or not, we do take this stuff to heart.  Anytime you find
yourself cursing the tool if you can find the time and patience to send
a note to the monotone devel list about why (and what you wished it was
doing instead, if you know) it would be most appreciated.  monotone is
already old enough that part of the problem is that longtime developers
are desensitized to some of the stupid warning/error messages it can
emit, in those cases where we know what it is trying to say.

Graydon and Nathaniel at some point mused that we should have a
'punish-monotone' command that would cause monotone to cry out in pain,
ask for mercy, and send a report to the mailing list that monotone was
punished for it's stupidity after running <insert last command>. ;)

> ------------------------------------------------------------
> 
> Of course there is also something else happening here. Monotone doesn't
> seem to understand the relative "worth" of different heads. If Richard
> has to get on a plane and pushes his yet unfinished changes, in reality

You're right of course, monotone has no built in way to judge the worth
of different heads.  On the monotone project, checking in changes on the
main branch is taken to be shorthand for "I believe this change is good
and ready for anyone."  If you have *unfinished* changes and want to
push them for backup purposes you should probably commit them to a
branch.  (Note that you can always *commit* them for local backup
purposes without affecting anyone else; but then you have to remember
not to push until you're ready.)

> nobody but Richard really cares about them. If I'm one of the listed
> users above updating or checking out I don't care about Richard's head.

monotone's certs are, eventually, meant to address these sorts of
concerns.  The original design was meant to provide infrastructure to
create software whose quality was "monotonically increasing."  So you
might have your buildbot infrastructure checkout, build, run your
testsuite, and only cert revisions which passed as "knowngood".  You
could then, as a developer, have your hooks set up to only pay attention
to revisions which carried a "knowngood" cert when running update, for
instance.

Once the basic VCS infrastructure has settled down there should be more
progress on the workflow stuff.

> Another thing I don't understand, is how creating multiple heads is any
> different from branching? 

Mechanically it isn't really, branches just provide nice support for
having longer running divergence.  If you're going to start working on
some new feature and expect it to be awhile before it's ready for prime
time, just work on it in a branch.  Other developers won't have to guess
that way if your "head" is a good one to update to, or if it should be
merged; it will be hidden away on it's own branch.  It's easy to
propagate changes between branches, and repeated propagates should do
the right thing.  So, once your shiny new feature is done, you can
propagate main branch to your experimental one, do all the messy merging
work, verify that it works right, then propagate back to the main
branch.

> Say in CVS, when I create a branch called "Mithro's Changes" I now have
> two "heads", the latest version of the main branch (which CVS refers to
> as HEAD) and the latest version of the "Mithro's Changes". At any stage
> I can in theory merge the two branches back together (which is a pain
> under CVS that nobody actually does it).

Exactly.  With monotone, it's not painful at all.  You can decide at
commit time that your work belongs in a new branch, repeated merges work
well, etc. etc..

> Just some thoughts...
> 
> Mithro (Who is generally hovers between the two above users)

Thanks very much for your time; end user feedback rocks!
-emile

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]