[Monotone-devel] Re: "prune-branch" cert implementation issues.

[Willem Rein Oudshoorn]

Nathaniel Smith <address@hidden> writes:

> On Sun, Jun 05, 2005 at 05:53:07PM -0400, Michael Stone wrote:
> > I'm attempting to give people a clean way to mark a revision as
> > "no-longer-a-head-for-branch-X".  There are two use cases for a feature
> > like this one:
> > 
> > 1) To ignore old branches which have subsequently been merged into the
> > mainline.
> > 2) To mark revisions as unsuitable for merging.
>
>
> (2) is actually incorrect to handle this way.  The goal is not to
> prevent people from merging some bad code into some good code; we
> can't do that in a distributed system.  Maybe someone has already done
> the bad merge, and you just don't know about it yet... there's no way
> for you to tell, and there's no cert you could add that would be other
> than ineffectual.
>  What _will_ work is something like "disapprove",
> that commits the inverse change.  It basically inserts something into
> the system that says "kill this code whereever you see it"; now it
> doesn't matter if someone has already spread the bad code around,
> because when they eventually merge in the disapprove node, the bad
> code will get stripped out again.

Ah, but for me that is a slightly different use case.  I do not
think that the major use case is killing bad code.

Because if you want to kill bad code, indeed just submitting
a reverse patch is the right way to do it.
BTW, what does disapprove do except just reversing the latest
patch?  Seems a little bit of overkill this command, almost as easily
you just checkout the old version copy it over the wrong one and
commit that.  

> 
> The more compelling use case for this, I guess, is the "dead end
> development" ones -- "I made some revisions, but, eh, I want to
> abandon them".  I'm not sure about this case either -- generally the
> way in monotone to say that one piece of code supercedes another is to
> make the superceding code a descendent of the superceded code, so
> there's some vocabulary for dealing with this case already.  But maybe
> someone wants to argue this has some advantage...?

But does that not look terribly ugly?    Of course it can be done
this way.  But you get nasty revision graphs just to state a simple fact.
I am now starting to use monotone, and what quite frequently happens 
is that I get something like:

            A
           / \
          B   C
       
first,  I work on B and extend B to

           A
          / \
         B   C
         |
         D

than I decide that actually D should be in a subbranch of A.
Now I can easily switch D to the new branch, but
avoiding multiple heads in the A branch is suddenly very tricky.
I have to make the correct merge from B (or D) into C 
without changing C.  So you get the following graph:

           A
          / \
         B   C
         | \ |
         D   E

just to say that: B is not a very interesting head in the A branch.

Note that for me the newly suggested cert is quite a weak statement:

* If this revision is a head in branch xxx,
  it is advisable not to use it.

Nothing is preventing anyone of doing anything with this revision.
For me it is not intended to force a policy on other developers.
It is just a hint to the user interface of monotone.  And
at the moment the user interface is monotone.

However I would like to make extensive use of branches, basically
for every feature just to play and test with it, I would like to make
a branch.  This allows me later to do some sort of cherry picking
with branches, merge in different functionality based on the branch name.
As a consequence it often happens that not that many people
are working on a single branch.   


Also, perhaps I think about the heads in monotone differently than you do.
For me, heads are a list of "active/interesting" version, the frontier
where people actually are developing nice new features. 
Of course "heads" has a nice mathematical notion.  
But in practice I don't care.

Finally, an other potential use case, but I have never experienced this one
so take it with a grain of salt:

Suppose we have two heads A and B, which have diverged a bit:

                X
            ..     ..
          lots    lots 
           of       of
          work     work
           |        |
           A        B

now someone merge A and B:

               X
       
           A       B
             \   /
               C

and it turns out the merge is quite tricky, the result does not
work and at the moment you just do not want to deal with it.

Supplying the new cert to C will make for all practical purposes
A and B head again.  So the developers can continue working on A 
and B and think about a way fix the problems in C.
Later you can either decide to fix C or reattempt a merge from
A' and B' (A' and B' descendents of A and B).


Wim Oudshoorn.