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.