refactoring and noting mv/rename after the fact

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Phillips wrote:
| That's the idea, something like that.  In my opinion, bzr-ng should
just make
| the obvious deductions (by comparing directory topology and file
contents)
| and not even bother to ask you unless you tell it to.  If an ambiguous
case
| arises (e.g., bzr-ng sees a file disappear and two new files appear
with the
| same contents as the disappeared file) then bzr-ng needs to ask.  Which
| should almost never happen.  "No news is good news".

Auto-detection of renames could well do the trick most of the time.

For commandline-oriented users, a well-implemented "bzr mv" could be
used in place of /bin/mv all the time, with an alias.  (a
half-implemented one would just be annoying, though.)  Ultimately,
rename(2)s don't always mean what they look like (because they're used
to atomically update files and such), so monitoring rename(2) wouldn't
be any help.  Bzr support in file managers would kick prodigious
quantities of ass.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCWsbg0F+nu1YWqI0RAuiWAJ9L3h2pACeqlsYMn5S7BXQ5ujTckgCfQDnH
/FDK1axcrCLsSceW9MzqmLA=
=5vsG
-----END PGP SIGNATURE-----