support assisting the decision about where an uncommitted change should be committed

Bug #227349 reported by Forest Bond on 2008-05-06
2
Affects Status Importance Assigned to Milestone
Loom
Wishlist
Unassigned

Bug Description

See also bug #227339

When switching threads, conflicts between uncommitted changes and the new base can arise.

These WT conflicts are sufficiently disruptive to warrant a --force requirement, and can result in a mildly destructive situation, as valuable changes in the WT mingle with the conflict and must be manually resolved before the user can even switch back to the thread he came from.

Example:
  Thread A is an base-level thread, thread B is work built on top of that.
  User is in thread A after cleaning up some changes, and they forgot to switch to their other thread.
  They make some changes in the same location as thread B, not realizing that the text is not their current tip.
  They realize that they aren't using their latest, and use "bzr switch B".
  At this point it tries to roll forward, and causes conflicts because of overlapping changes, even though there weren't any changes in thread A that needed to be merged into thread B.

The last point is what makes this different from bug #227339

John A Meinel (jameinel) on 2008-05-06
description: updated
John A Meinel (jameinel) on 2008-05-06
description: updated
John A Meinel (jameinel) wrote :

Another example which is somewhat less "trivial".

A user has been struck with inspiration and gone on a bug fixing spree, and now needs a way to separate out their changes into a more logical set of patches.
At this point they have a fairly involved set of changes in the WT which are being split up while switching between threads.
While in the process of deciding what changes go where, they sometimes do a test switch, to see if this change would fit best in that thread.
If that ends up in a conflict,
  A) they probably don't want it in that thread after all, and
  B) they can't switch to another thread because they now have conflicts that have to be resolved.

having a way to avoid the switch if it would conflict allows them to poke around a bit to find where things fit best, without going through a time-consuming conflict resolution process before they get to jump again.

description: updated
description: updated
Forest Bond (forest-bond) wrote :

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.

Robert Collins (lifeless) wrote :

So, there are several things to tease apart here:
 - how do you commit changes to a different branch/thread
 - what is the primary use for switch
 - whats the best default.

I'll support a --require-clean mode on switch or something, to say 'dont switch if there are conflicts', but defaulting to that seems really weird - pull itself can conflict when a directory is deleted and there are pyc files left behind; forcing switch to break when that happens would just annoy me :)

Changed in bzr-loom:
importance: Undecided → Wishlist
status: New → Confirmed
summary: - Should refuse to switch threads if doing so would cause a WT conflict
+ support assisting the decision about where an uncommitted change should
+ be committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers