pulling a loom resets to last-recorded state
Bug #201409 reported by
Aaron Bentley
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Loom |
Triaged
|
High
|
Unassigned | ||
Bug Description
I needed to split a thread-- it turned out that some of the work I had done should not have been combined with other work.
I wanted to split the thread at a particular revision, and
So I did this:
$ bzr create-thread subscription-
$ bzr pull -r thread:ORM-updates .
(and then I was going to uncommit the revision from ORM-updates that didn't belong in subscription-
This caused the loom to be reset to its last-recorded state (I think). This is obviously not what I wanted. It's not even clear how to *get* what I wanted, since the problem is pulling ., not the revision spec.
Revision history for this message
| John A Meinel (jameinel) wrote | #1 |
Revision history for this message
| Robert Collins (lifeless) wrote Re: [Bug 201409] Re: pulling a loom resets to last-recorded state | #2 |
| Changed in bzr-loom: | |
| importance: | Undecided → High |
| status: | New → Triaged |
To post a comment you must log in.
Something does seem a little fishy here.
It seems like maybe doing a "bzr record" first would make sure that the loom state is set on disk and then the pull wouldn't overwrite it.
Regardless, it would seem that "bzr pull" shouldn't smash the target loom record. Just like we do now with file contents, 'pull' preserves local modifications.