| 2009-07-04 17:13:10 |
Martitza |
bug |
|
|
added bug |
| 2009-07-08 05:32:19 |
Martin Pool |
bzr: importance |
Undecided |
High |
|
| 2009-07-08 05:32:19 |
Martin Pool |
bzr: status |
New |
Confirmed |
|
| 2009-07-10 00:59:26 |
Martitza |
removed subscriber Martitza |
|
|
|
| 2009-07-14 23:44:05 |
Robert Collins |
tags |
|
commit dirstate inventory |
|
| 2009-07-15 00:01:45 |
Robert Collins |
tags |
commit dirstate inventory |
dirstate |
|
| 2009-07-15 00:02:26 |
Robert Collins |
summary |
bzr mv (rename in place) causes commit to fail depending on specific filenames |
bzr mv (rename in place) can corrupt dirstate with specific ordering |
|
| 2009-07-15 00:03:13 |
Robert Collins |
description |
Martin (gzlist@googlemail.com) raised this in the mailing list. He's on vacation, and this bug (if true) is too important to delay.
I have tried to provide discriminating examples based on his original remarks. See the thread entitled "Strange failure with mv and commit" for historical reference.
One begins to wonder if the collation order of the names matters. As crazy as this sounds, let us do an experiment. We will create a file named '2' and we will either demote it (to '1') or promote it (to '3') and then return to '2'.
First, we do the promotion case. This works:
bzr init t1
cd t1
touch 2
bzr add 2
bzr mv 2 3
bzr commit -m "call it 3"
bzr mv 3 2
bzr commit -m "call it 2"
And this fails:
bzr init t1
cd t1
touch 2
bzr add 2
bzr mv 2 1
bzr commit -m "call it 1"
bzr mv 1 2
bzr commit -m "call it 2" |
bzr init t1
cd t1
touch 2
bzr add 2
bzr mv 2 1
bzr commit -m "call it 1"
bzr mv 1 2
At this point the dirstate is corrupt (bzr check should report this; tree._validate() does report it. |
|
| 2009-07-15 00:39:33 |
Martitza |
description |
bzr init t1
cd t1
touch 2
bzr add 2
bzr mv 2 1
bzr commit -m "call it 1"
bzr mv 1 2
At this point the dirstate is corrupt (bzr check should report this; tree._validate() does report it. |
bzr init t1
cd t1
touch 2
bzr add 2
bzr mv 2 1
bzr commit -m "call it 1"
bzr mv 1 2
At this point the dirstate is corrupt (bzr check should report this; tree._validate() does report it.
If we attempt to commit, we will get a traceback like the one reported below by Martitza in a comment on 2009-07-04. That is,
bzr commit -m "call it 2"
gives the traceback shown in the following comment.
|
|
| 2009-07-15 01:15:20 |
Launchpad Janitor |
branch linked |
|
lp:~lifeless/bzr/bug-395556 |
|
| 2009-07-15 01:20:50 |
Robert Collins |
summary |
bzr mv (rename in place) can corrupt dirstate with specific ordering |
dirstate.set_state_from_inventory is broken with forward-edits. |
|
| 2009-07-15 01:20:57 |
Robert Collins |
bzr: status |
Confirmed |
Fix Committed |
|
| 2009-07-15 01:21:03 |
Robert Collins |
bzr: status |
Fix Committed |
Confirmed |
|
| 2009-07-15 01:21:03 |
Robert Collins |
bzr: assignee |
|
Robert Collins (lifeless) |
|
| 2009-07-15 02:41:42 |
Robert Collins |
bzr: status |
Confirmed |
Fix Committed |
|
| 2009-07-20 03:47:59 |
Robert Collins |
bzr: status |
Fix Committed |
Fix Released |
|
| 2009-07-20 03:47:59 |
Robert Collins |
bzr: milestone |
|
1.18 |
|
