Comment 2 for bug 227349
Revision history for this message
| Forest Bond (forest-bond) wrote Re: Should refuse to switch threads if doing so would cause a WT conflict | #2 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
For me, this situation typically arises if the user is carrying several changes around with him in the WT as he switches threads. Eventually, a WT change may conflict with a thread that the user switched to, even if the user has no intention to commit that particular change on that particular thread. However, now, in order to restore mobility to his loom, the user must resolve the conflict.
For instance, suppose I have three threads:
C
B
A
Now, suppose I make some changes while my current thread is B, but then I realize that some of those changes should be committed in A, some in B, and some in C. I will probably `bzr commit' the changes that belong in B, and then do `bzr down-thread' to commit the changes I want in A. But what if the changes destined for C conflict with A? If I had known ahead of time that this was the case, I might switch to C to commit those changes first, or I might shelve the changes for C, commit changes in A, switch to C, and then unshelve the changes for C.
The primary distinction between this issue and that covered by bug #227339 is that, here, the conflict is between the WT and previously committed revisions in the thread being switched to, whereas #227339 deals with pending merges as a result of moving up the loom after committing to a lower thread.