refactoring and noting mv/rename after the fact
aaron.bentley at utoronto.ca
Mon Apr 11 19:50:08 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Daniel Phillips wrote:
| That's the idea, something like that. In my opinion, bzr-ng should
| the obvious deductions (by comparing directory topology and file
| and not even bother to ask you unless you tell it to. If an ambiguous
| arises (e.g., bzr-ng sees a file disappear and two new files appear
| 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar