"bzr mv considered harmful" or "IDE != command-line"

Andrew Cowie andrew at operationaldynamics.com
Sat Mar 8 15:18:40 GMT 2008

On Fri, 2008-03-07 at 14:00 -0500, John Yates wrote:
> A bzr design goal is the ability to record information about file moves
> and renames.  This comes down to two tasks: ... Add to
> that the fact that there will never be a way to guarantee that bzr is
> privy to every modification of a workspace and it is no surprise that
> getting this UI model correct has proven so challenging.  Once one
> acknowledges that arbitrary changes to a workspace may occur without bzr
> being informed then simply attempting to enumerate fully all scenarios
> that need to be handled is a challenge.

Classic long tail problem; but that doesn't meant we can't try to have
superb behaviour for the high percentile cases.

> With the increasing discussion of smoothing the path for integrating bzr
> into various non-commmand-line-based environments perhaps some thought
> should be given to living without access to a command-line.  As I see it
> this would mean supporting an alternative UI model in which all adds,
> moves, renames and deletes would have to be identified after-the-fact,
> at the time of a commit.

Not necessarily then, just not in the imperative as you describe it. The
existence of `bzr mv --after` at least gives one the ability to
workaround the problem right now, even if manually.

> Such an after-the-fact scheme .... flailing away, ... flailing....
> Once flailing is complete one turns ... One flails with
> arbritrary, ...

Minus the flailing, a case I hit frequently is dealing with the
consequences of the *OUTSTANDING* refactoring support in the Java IDEs.
Moving a class from one package to another results in it moving on disk
from one directory tree to another [potentially new] one (along with
changes to all files in the project referencing that name); a rename of
the class usually involves a rename of the file it lives in.

One _can_ deal with these after the fact. A more likely scenario is
figuring out how to get (in this case, Eclipse) to issue an appropriate
command to bzr to tell it what it has done. That's a bit outside the
scope of bzr-eclipse (which adds commands to do VCS tasks, as opposed to
hooking into behaviours in other areas of Eclipse) but still, is an
interesting challenge.


Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.


Sydney   New York   Toronto   London
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080308/d86f5a36/attachment.pgp 

More information about the bazaar mailing list