On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> 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 Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel