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

[Rob Schoening]

A suggestion to help prevent this from happening in the first place:

 

One feature that I've always wished for with CVS (and Monotone) is a slight bit more interactivity with the editor on commit. 

 

Intuitively, I've always wanted to be able to exclude files from commit by simply deleting the appropriate CVS: or MTN: lines in the editor that correspond to the files that I want to exclude.

 

As an enhancement to that, it would be equally useful to be able to have an option to automatically include the diffs in the editor so it's even easier to a) write changeset comments and b) double-check that something isn't being erroneously included when it should really be part of a different changeset.

 

For me, at least, this would go a long way to avoid logically separate changesets getting clubbed together in the first place though either a) laziness or b) mistake.

 

RS
 

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.


Hugo


--
                   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


_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel