Re: New branch name with no other changes

Nuno Lucas wrote:
> Hello,
>
> On Mon, Jun 13, 2011 at 00:14, Stephen Leake
> <[email protected]> wrote:
>   
>> Hendrik Boom <[email protected]> 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.

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.

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.

Maybe the documentation needs a FAQ section?

Either way these are just passing idle thoughts and ideas. As Nuno said, 
feel free to disregard. :-)

Tony.

>
> Best Regards,
> ~Nuno Lucas
>
>   
>> --
>> -- Stephe
>>     
>
> _______________________________________________
> Monotone-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/monotone-devel
>