[Top][All Lists]

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

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

From: Hugo Cornelis
Subject: Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)
Date: Thu, 24 Aug 2006 12:32:08 -0500

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 different revisions. You don't have to check in your
entire workspace. You can use restrictions to check in only certain

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.


                   Hugo Cornelis Ph.D.

                 Research Imaging Center
  University of Texas Health Science Center at San Antonio
                   7703 Floyd Curl Drive
                San Antonio, TX  78284-6240

                   Phone: 210 567 8112
                     Fax: 210 567 8152

reply via email to

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