Daniel Carrera wrote:
Hello,
I am currently a Darcs user and I'm interested in Monotone's greater
data integrity assurance. But I have a question about committing:
I am the sole programmer at a small business. Often I will be working on
Feature_A when something else comes up (Issue_B) that requires immediate
attention (boss wants a new feature asap, customer has a problem, etc).
So I deal with Issue_B and when I'm done I go back to working on
Feature_A. My work is a web application, so it is perfectly reasonable
to solve Issue_B, send the changes to the server and then continue with
Feature_A.
Anyways, at this point I would like to commit the changes related to
Issue_B. But I already have a bunch of changes for Feature_A and I don't
want to mix the two together. These are logically different changes and
should be on different patches. I would like to know how Monotone could
help me deal with this situation. This situation happens every week. I
am often working on improving the crappy source code I inherited from my
predecessor or fixing security issues while the boss wants to add a new
feature. So I need a simple way to say "put these changes in the patch
but don't include these other ones".
My current solution is Darcs, which indeed makes the above easy. When I
run "darcs record", darcs shows me the changes one at a time, and I can
tell it which ones to include in the patch. Another equally good
solution is: (1) record the current changes for Feature_A, (2) work on
Issue_B, (3) record the changes for Issue_B, (4) UN-DO step (1), and
continue working on Feature_A. This latter option is actually more useful.
Anyways, does Monotone offer either solution to my problem? Or perhaps
it offers a third solution that I have not thought of yet?
Thanks,
Daniel.
When I need to do things like this, I check out a new workspace (mtn co
../new-work-space) and then I make the hot fix change there and commit
it. This keeps your Feature_A change from being included in the commit.
You could also do this in a separate branch.
After you commit the hot fix (Issue_B), you can continue working on
Feature_A as you were, commit and then merge later (mtn commit, mtn
merge, see monotone branches can have two heads), or you can merge that
change into your Feature_A workspace (mtn up) and continue from there.
--
Matthew Nicholson
matt-land.com
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel