Bazaar and Visual Studio

[Stephen J. Turnbull]

Alexander Belchenko writes:
 > Kuno Meyer пишет:

 > > - automatic rename tracking (--> no after-the fact reconstruction
 > > of renames or after-the-fact modification of project files)
 > 
 > What it means?

I can think of three places where the file needs to be renamed: in the
working tree's directory, in the build control scripts (Makefiles on
Unix, .project files in Xcode on Mac, and I suppose on Windows they
get recorded in the Microsoft cloud in Redmond, or maybe in the
registry ;-), and in the VCS.  The rename needs to be tracked in the
VCS's history so that old versions under a different name can be
diffed, logged, or blamed without remembering the old name.

There may be other places I haven't thought of.  Perhaps "properly
reloaded" (see below) refers to recompiling and linking the project,
which could be considered part of "tracking", I guess.  E.g., Emacs
has a command `byte-compile-and-load-file' which converts the Lisp
source to virtual machine ("byte-compiled") code, then reloads the
compiled code into Emacs.

This should all be accomplished with *one* "rename" command,
preferably with an explorer-type interface (i.e., click on file name
in project directory window, and type the new name over the old name),
as well as more CLI-like interfaces (pop-up dialogs and an actual
command interpreter).

By "reconstruction" I assume he's referring to git-style copy/rename
inference, and by "modification" I assume he means the usual grep-and-
write-a-script-to-global-replace dance that we have historically done
on Unix when a file absolutely positively must be renamed.  And the
command should be sufficiently smart to rename build products, too.
Eg, "a.c" -> "b.c" implies "a.o" -> "b.o" and "a.exe" -> "b.exe".

 > > - be sure that anything gets properly reloaded after file
 > > modifications (Visual Studio project files)
 > 
 > And this one?

Not sure, but see above.