monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: CooSoft Support
Subject: Re: [Monotone-devel] New branch name with no other changes
Date: Thu, 16 Jun 2011 09:38:36 +0100
User-agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)

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.

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/monotone-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]