Re: [Monotone-devel] Workflow with Monotone

[Wim Oudshoorn]

On Sun, Jun 05, 2005 at 07:23:46PM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on 04 Jun 2005 22:08:56 +0200, Willem Rein 
> Oudshoorn <address@hidden> said:
> 
> woudshoo> Use case I - Discard work
> woudshoo> .........................
> woudshoo> 
> woudshoo> I have developed on my own branch project.wim
> woudshoo> But I have been out of the loop for a while, so I want to
> woudshoo> start again.
> woudshoo>           project        project.wim
> woudshoo> 
> woudshoo>            A  
> woudshoo>             \_______________  B (empty commit)
> woudshoo>                               | did work
> woudshoo>                               C
> woudshoo>           .
> woudshoo>           .
> woudshoo>           .
> woudshoo>           X
> woudshoo>             \______________  Y  
> woudshoo> 
> woudshoo> 
> woudshoo> Y will be in the same branch, but I do not want C to show
> woudshoo> up.  So I would like to mark "C" as a non-head on the branch
> woudshoo> project.wim
> 
> An option is to have project.wim.1, project.wim.2 and so on, or
> something similar.  With some discipline, you can propagate between
> those sub-branches and may be able to combine things nicely.

Yes indeed, I know I can do that, but it seems quite cumbersome, and even
more tricky to automate.  
If I can use consistently one branch it is easer to just type in:

   build project.wim

And do not need to remember what particular numbered version I am in right now.
 
> woudshoo> Use case II - Discard work
> woudshoo> ..........................
> woudshoo> 
> woudshoo> A made a change I which is a mistake
> woudshoo> 
> woudshoo>            A
> woudshoo>            |
> woudshoo>            B
> woudshoo> 
> woudshoo> B is a mistake, so I want to do:
> woudshoo> 
> woudshoo>           A          
> woudshoo>           | \
> woudshoo>          *B* C (empty commit)
> woudshoo> 
> woudshoo> and continue to work on C.  Just mark
> woudshoo> B as a non-head and I am happy.
> woudshoo> If I later decide to continue on B, I just
> woudshoo> have to explicitly checkout revision B
> woudshoo> and commit again to create
> woudshoo> 
> woudshoo>           A
> woudshoo>           | \
> woudshoo>          *B*  C
> woudshoo>           |
> woudshoo>           X (empty commit)
> 
> An option is to use disapprove on B.  This creates a new revision
> (direkt child of B) containing the "anti-patch" of B, and you can
> continue from there:
> 
>   A
>   |
>   B
>   |
>   Bd
>   |
>   C

Yes, but it seems such a hack, from the revision graph it is not
very clear what you have done.
Also, what happens if you have:

       A
       | \  
       B  C
       |
       D

where B and C are independendly created first, and later it is agreed
that we should continue with C and not on D?

So we do not want D anymore, but it will forever be  ahead, unless you
do something nasty like merging D with C:

     A
     | \
     B  C
     |  |  
     D  |
      \ |
        E

where E should equal C.  
Again, from the revision graph it is not clear at all.  While just
marking D as a non-head for the branch does not clutter the graph,
and you can check by looking at D (and maybe colour it in a graphical 
display.) that we consider this head to be dead.

Also, again, (I discover I am a little bit passionate about this)
If I dissapprove a revision, conceptually that is NOT the same
as just applying the reversed last changeset.  
For example how would you dissapprove a merge:
 
     A   B
      \ /
       C



> woudshoo> Use case II - Retroactive branching
> woudshoo> ...................................
> woudshoo> I started making changes and commited them
> woudshoo> in branch project.wim, but I suddenly decide that
> woudshoo> they should NOT be in project.wim but in 
> woudshoo> project.wim.experiment
> woudshoo> 
> woudshoo> So I have
> woudshoo> 
> woudshoo>          A [project.wim]
> woudshoo>          |
> woudshoo>          B [project.wim]
> woudshoo> 
> woudshoo> 
> woudshoo> And I want B to be in project.wim.experiment.  What I
> woudshoo> do is:
> woudshoo> (1) add branch certifacet project.wim.experiment to B
> woudshoo> (2) mark B as a non head for project.wim
> woudshoo> 
> woudshoo> 
> woudshoo> 
> woudshoo>         A [project.wim]
> woudshoo>         |
> woudshoo>         B [*project.wim*]
> woudshoo>           [project.wim.experiment]
> 
> There's no need to make B a non-head of project.wim.  Actually, that
> would mean that project.wim ends up having no heads, or that A is
> considered it's head. 

I do not want A to be considered head.  Actually I should have drawn a
more complete picture:

Desired situation:

           A [project.wim] 
           |              \_________ B [project.wim.experiment]
           C [project.wim]


But I made a mistake and have:

                A [project.wim]
               / \
[project.wim] C   B [project.wim]

and I want to fix that.

>  And really, none of that is needed, just check
> out or update to the experimental branch, and whatever you commit
> thereafter will go to that branch, with no regard to what happens in
> project.wim.

Yes, I know.  But I might want to continue working on project.wim, but
starting at A and not be concerned with B,  so I definitely do not want
B to be head of project.wim.

 
> woudshoo> Use case III - adding other metadata
> woudshoo> ....................................
> woudshoo> If we want to make a new build with a different version
> woudshoo> number, it would be nice to just do an empty commit
> woudshoo> and attach the new compiler flags and version number
> woudshoo> to the new revision.
> 
> Again, there's talk of versioned certs, and that would solve your
> problem.  With the current monotone, you can rely on the multi-
> value properties of certificates (you can have several certs with the
> same name and different values) for the version number, and have the
> other cert names include the version they apply to.  Like this:


> Version:  1.2.0.3
> Version:  1.2.0.4
> Build 1.2.0.3: machine xxx: passed|failed
> Build 1.2.0.4: machine xxx: passed|failed
> Build arguments 1.2.0.3:  special compiler flags used
> Build arguments 1.2.0.4:  special compiler flags used
> Smoketest 1.2.0.3: ... passed| failed
> Smoketest 1.2.0.4: ... passed| failed
> Regressiontest 1.2.0.3: ... passed | failed
> Regressiontest 1.2.0.4: ... passed | failed
> Bug fix implemented 1.2.0.3: bug nr
> Bug fix implemented 1.2.0.4: bug nr
> Devepment environment 1.2.0.3:  rev id of development environment used
> Devepment environment 1.2.0.4:  rev id of development environment used
> 
> I agree, that could become a lot of certs...

Yes you are right, this would work.  (of course it does not make sense
to add Bug fix implemented 1.2.0.3 versus 1.2.0.4 because any source
change will make a new revision :-)

And this is really one of my minor use case.

Oh and I am very interested to what the versioned certifaces will be.
I am not sure I like the sound if it.  Of course it would be nice 
to change certificates later.  But versioning?  it can lead to
all kind of interesting merge problems on metadata.  
Also, changing metadata, which we would like to do when for
example a test failed, but it turns out later that for some stupid
reason the test script failed and after reruning they succeed,
can be done in different ways.  
For example add a special cert saying:

Ignore cert:
   Value:  Ignore certificate with id: xxxxxx

Which of course itself can be ignored.   The ignore certs
will form a DAG in itself and can safely be parsed.  
However it is 10 to 3 in the night, so I will not elaborate
on this right now.

Hope my remarks made some sense, and thanks for your input.

Wim Oudshoorn.