Re: [Monotone-devel] New branch name with no other changes

[Hendrik Boom]

On Thu, Jun 16, 2011 at 09:38:36AM +0100, CooSoft Support wrote:
> Nuno Lucas wrote:
>> Hello,
>>
>> On Mon, Jun 13, 2011 at 00:14, Stephen Leake
>> <address@hidden> wrote:
>>   
>>> Hendrik Boom <address@hidden> writes:
>>>     
>>>> So my real problem was not knowing about the approve command.  I may
>>>> have heard about it before, but if I did assumed it was for reporting on
>>>> the success of testing, rather than providing a branch name.
>>>>       
>>> Hmm. I would have thought so, too. But that's not what the manual says
>>> (http://www.monotone.ca/docs/Review.html#Review); it seems 'approve' is
>>> a synonym for the 'cert' command I use for creating a new branch.
>>>
>>> I guess it makes sense when compared to 'disapprove', but it sounds odd
>>> in my (our) work flow.
>>>
>>> 'testresult' is for recording the results of testing.
>>>     
>>
>> In my view, any of those commands do what one wants when creating a
>> fork, but none is clear on what it does.
>>
>> I would vote for a "mtn fork <new_branch_name>" command. If no options
>> given would create a new branch on the current workspace revision.
>> No workspace update would be done by default, but could be done by
>> adding "--update" (or "-u").
>> Other option would be "-r <revision>", so one could fork from a
>> specific revision independently of the current workspace.
>> A third, arguable, option could be if the commit is "real" (cert) or
>> "virtual" (just changes the "_MTN/options" file). It could be a
>> "--delayed" or "--local" option. But I don't have strong feelings
>> about this one.
>>
>> I don't have a very strong reason to add this command. But I find that
>> I create a new branch rarely enough that I always have to go see the
>> manual on how to do it. And doing it at commit time is too late in the
>> game -- most of the time I have to undo that commit because I forgot
>> to branch.
>>
>> The decision to branch is done mostly a long time before the real
>> commit, so there is a good chance to forget about it at commit time.
>> Doing "dummy" commits or manually editing the _MTN/options file feels 
>> "dirty".
>>
>> Well, this is just to give an user opinion (using monotone since 0.20
>> something). Feel free to disregard.
>>   
> This is exactly why we adopted  the mtn cert ; mtn update approach to  
> creating branches, because one forgets at check in. :-)
>
> I guess one could use lua to add your proposed fork command, but  
> wouldn't branch perhaps a better name as in mtn branch... or would that  
> be too confusing?
>
> My _slight_ concern is that mtn provides an easy enough way to do this  
> at the moment using two simple commands and we might start down the road  
> of interface clutter as one can see with such tools as git.

I appreciate the problem of interface clutter.

> 1) Yes the documentation, which I think is very good btw, needs to make  
> the alternate `mtn cert... mtn update' approach to branching much more  
> obvious than it is now and why you might want to do it that way as  
> against the mtn ci -b way.

Yes, the documentation is probably an adequate place to solve this 
problem.  Possibly a note in the section on mtn approve, giving the 
two-step process.

And having the tutorial go as far as a real named fork might also be 
useful.  As well as the rationale -- that Beth is going to be working on 
a major change that will take many checkins to become stable,  she 
doesn't want to interfere with the others' work, but she does want it 
to be visible to the others so they can comment on it.

>
> 2) Implement a global rc file mechanism, I read the comment about  
> wrapping it in a script, yup that is a possibility (certainly for now).  
> but most tools have the concept of global and user rc files. If this was  
> done then interface extensions could more easily/practically be rolled  
> out via the extras package.

Careful with this.  You can reasonably want such scripting by the user, 
ny the project and system managers, by the Linux distribution, and by 
the monotone developers themselves. 

It should be possible -- and encouraged -- for them all to do it by 
different files.

>
> Maybe the documentation needs a FAQ section?

And if the regular documentation were thorough enough, each FAQ could 
link to the exact place in the documentation where it's answered.

-- hendrik