Re: [Monotone-devel] Questions about Monotone

[Matthew Nicholson]

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