Bazaar Version Control System

Using bzr mv --after on a directory (as opposed to a filename) fails

Reported by Andrew Cowie on 2007-04-20
30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Lukáš Lalinský

Bug Description

While `bzr mv --after` works as advertised on a file that has been renamed by a tool other than `bzr mv`, it unfortunately fails when given two directory names as arguments. The failure looks like this:

$ bzr mv --after old new
bzr: ERROR: Could not move to new: new is not versioned

Duplicated by Matthew Fuller and Martin Poole while chatting in #bzr. They remarked:

poolie:
"yes you're right"
"regular mv works but not --after"
"please do file a bug and we'll try to fix it for the rc on monday"

fullermd:
"After all, if the last arg to 'mv' is a directory, it tried to mv the earlier stuff _into_ it. Thus..."
"Have to special-case it, I s'pose. How evil."

The fact that `bzr mv --after` works on files is terrific, supporting refactoring by external [to Bazaar] tools; directory renames are, however, also a frequent use case for Java developers who, using Eclipse, can rapidly refactor package names, resulting in directories [and in fact, entire directroy trees] being [arbitrarily] renamed, so I hope you'll find time to fix this glitch.

AfC

Andrew Cowie (afcowie) on 2007-04-20
description: updated
John A Meinel (jameinel) wrote :

Confirmed. We detect whether the target is a directory so we can switch between "bzr mv foo bar" meaning rename "foo" to "bar", and move "foo" to "bar/foo". However, this is done before detecting if the source exists.

What we should do is check if source exists, then check if target exists (and whether it is a dir).

Also, we have some problems if source and target both exist, and target is a directory. Because then it is unclear what you want. I'm okay with failing in that circumstance.

Changed in bzr:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
John A Meinel (jameinel) wrote :

Current workaround is to just "mv target/dir source/dir; bzr mv source/dir target/dir".

Changed in bzr:
assignee: nobody → daniel-thewatkins
status: Confirmed → In Progress
Daniel Parks (dp+launchpad) wrote :

Sent a fix to the mailing list. I've attached a bundle.

Daniel Parks (dp+launchpad) wrote :

Updated fix based on feedback from James Westby.

Changed in bzr:
assignee: daniel-thewatkins → nobody
Alexander Belchenko (bialix) wrote :

PING. This bug marked as In Progress. Does anybody working on this? It still presents in 1.0.

Daniel Parks (dp+launchpad) wrote :

My bad. I was working on this but ran out of time and energy. There was further feedback from Aaron Bentley that needed to be incorporated. I think it amounted to support for branches within branches (I forget the correct term) and better test coverage.

Changed in bzr:
status: In Progress → Confirmed
Changed in bzr:
assignee: nobody → luks
milestone: none → 1.3
status: Confirmed → In Progress
Changed in bzr:
status: In Progress → Fix Committed
milestone: 1.3 → 1.4
Alexander Belchenko (bialix) wrote :

bzr.dev revno.3293

Changed in bzr:
status: Fix Committed → Fix Released
Timmie (timmie) wrote :

this is still present on the current bzr version 1.3.1 in Ubuntu

Matthew Frizelle (gleebtorin) wrote :

I'd call this a non-issue. I can make this work, reliably. Please tell me if I'm doing something wrong, I've only been using Bazaar for a day or two, but this seems to be "The Right Way". I've attached a log of what I did to make it work.

Bazaar (bzr) 2.0.0 :

I can confirm the bug to be still present:

if I refactor externally the source tree with some tool or ide, and then I attempt to do:

bzr mv --after src/olddir src/eu/mavior/newdir

bzr reply with:

bzr: ERROR: Could not move olddir => newdir: src/eu/mavior is not versioned

The refactoring involved the creation of the eu/mavior/newdir directory.

Changed in bzr:
status: Fix Released → Confirmed
Robert Collins (lifeless) wrote :

Marco, please file a new bug.

Changed in bzr:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers