monotone-devel
[Top][All Lists]
Advanced

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

Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)


From: Justin Patrin
Subject: Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)
Date: Thu, 24 Aug 2006 10:41:24 -0700

On 8/24/06, Hugo Cornelis <address@hidden> wrote:
On 8/24/06, Justin Patrin <address@hidden> wrote:
> Since each revision is one monolithic set of changes you would be
> better off checking in each of the things you want a s different
> revisions....as different revisions. You don't have to check in your
> entire workspace. You can use restrictions to check in only certain
> files/directories.
>

People under time pressure do not always think that way.  My post is
about the difference between common practice and best practice, and
how to bridge between them.

> If you really need to "split" a revision you can always make a
> checkout of the revision you want to split then revert all but 1 of
> the changes and check this in. Then repeat for all of the different
> things you want to split. Of course you'd need to merge these again.
>

I agree, but it would be useful if monotone could help a bit here.  I
have seen quite frequently the scenario where, in a product release,
under a lot of time pressure, a coder solves say 5 bugs and 5 issues,
next does a commit.  Allowing and helping to split this up in 10
different changesets that can be applied where appropriate, does make
a lot of sense to me and I think it would be nice if monotone supports
such a workflow.


My point was: How would monotone know how to do such a thing? All of
your changes were checked in as the same revision. Monotone has no way
of knowing which of these changes you want to split into different
revisions. It can't just choose changes in each file as a different
revision as:
1) Checkins in multiple files can be part of the same fix
2) Multiple changes in one file may be parts of different fixes

So the only way to split it would be to manually revert the changes
for all but one fix and then check this in (or to check out the parent
rev of the rev you're talking about, then using pluck to pull the
changes from the rev you want to split, then reverting the changes for
all but one fix. This would be the "right" thing to do.)

--
Justin Patrin




reply via email to

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