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

[John Yates]

A bzr design goal is the ability to record information about file moves
and renames.  This comes down to two tasks:

1) providing a storage format that can record/track such information

2) developing one or more UI models to acquire the information to be
recorded

A significant amount of bzr design effort and bug fixing has gone into
supporting a UI model that assumes users always work with a command-line
and that move, rename and delete events will be captured on-the-fly by
persuading users and their tools to substitute a bzr alternative for
classic add, move, rename and delete operations.  The need to capture
the edits that have occurred on a workspace has lead bzr into the
non-core, tortured realm of carrying out imperative operations on a
user's workspace.  Given the differing semantics of various platforms
this already is a complex composition of functions to get right.  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
acknowleges 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.

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.  At least in spirit, Lukas' automv plugin seems
to be a step in this direction.  One could further argue that while the
UI is far from polished bzr already can handle adds in this fashion.

Such an after-the-fact scheme attacks integration from the other
direction by focussing on a pre-existing, natural separation of
concerns.  That is, when flailing away, until one reaches a commitable
state, ideally one wants to focus on flailing without worrying about
which tools to use and whether they properly inform the VCS of facts to
be included in the next commit.  Once flailing is complete one turns
one's attention to preparing the best, most descriptive commit possible.
This natural alternation of activities leads to an equally natural
division of responsibilities between tools.  One flails with arbritrary,
potentially domain specific tools (e.g. ECAD, web development, etc) that
in all likelihood have never been taught about any VCS.  Then, when the
time comes to commit one takes up a commit composition tool.

A month and a half ago I posted a long rambling note ("Of renames,
copying, identity, workflows and code review") on this subject:

http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/36
473

I suspect that because of its length nearly no one other than JAM read
it.

/john

John Yates, Netezza     work: 508-665-6897
200 Crossing Blvd       fax:  508-665-6811
Framingham, MA 01702    cell: 781-467-8977