Re: [Monotone-devel] [PATCH] head selector

[Brian Downing]

On Sun, Jun 26, 2005 at 09:36:51PM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Sun, 26 Jun 2005 14:27:05 -0500, Brian Downing 
> <address@hidden> said:
> 
> bdowning> The current update behavior without a revision is to do
> bdowning> something like "update to the newest decendent of the
> bdowning> current revision limited to ones in the specified branch."
> bdowning> If you want to update "backwards" in the tree, you need to
> bdowning> specify a revision explicitly somehow.
> 
> Hmm, that sounds like trying to make a rational explanation for
> something that's less than intuitive.  Or maybe it's me, but if I way
> "update to that branch", I really want that to happen, whether the
> head of that branch is a decendent of my current revision or not.

I agree, it totally violates the principle of least suprise in my
opinion...  EXCEPT for the case where you have multiple parallel lines
of development going on in the same branch - then that behavior is
pretty much required.  Otherwise you need to look at a revision graph
every time you want to update with your co-workers' changes.

(This model of development isn't supported too well since there's no
easy merge operation to use in this case, though.)

My take on this was mostly formulated by this IRC conversation:

01:00 <bdowning> Shouldn't a "monotone update -b
        net.venge.monotone.precise-cdv" in a working directory checked
        out from the mainline (currently i:afa6) move you to the head of
        the other branch?  I just get "monotone: already up to date at
        afa604dcb0f10c0d4bfec25e1dfef1fd4676df7e", which isn't terribly
        helpful.  To switch branches I have to find the head manually
        and go to it.
01:01 <njs`> oh, really?
01:01 <njs`> oh, wait, right
01:01 <njs`> what's going on is: update with no rev argument always goes to a
        descendent
01:02 <njs`> passing -b will change how update chooses which descendents are
        okay to go to
01:03 <bdowning> hmm.  I see.  I think that behavior is kind of surprising at
        first glance, at least coming from CVS (which is the only other
        thing I know of with explicit named branches).
01:03 <bdowning> s/know of/know/
01:03 <njs`> yeah, it does seem suboptimal.
01:05 <bdowning> Worse, after the no-op the branch option has changed in
        MT/options, even though the current revision is still in the
        first one.
01:05 <njs`> ew.
01:05 <njs`> that's definitely a bug.
01:06 <njs`> I wish someone would implement head selectors, this is yet
        _another_ situation they would be useful for :-)

But then again, I don't really like the "branch lock" feature when given
an explicit revision that isn't a member:

:; ~/src/monotone/monotone update -r h:net.venge.monotone.cvssync
monotone: expanding selection 'h:net.venge.monotone.cvssync'
monotone: expanded to '7b88f7c9b843cae0b068b5232edf812c9b2b367d'
monotone: selected update target 7b88f7c9b843cae0b068b5232edf812c9b2b367d
monotone: misuse: revision 7b88f7c9b843cae0b068b5232edf812c9b2b367d is not a 
member of branch net.venge.monotone
monotone: misuse: try again with explicit --branch

-bcd