refactoring and noting mv/rename after the fact

[Martin Pool]

On Mon, 2005-04-11 at 13:19 -0400, John Yates wrote:
> One gripe I have with systems that claim that they support
> versioning of mv/rename is that, unlike the other operations
> I perform in my sandbox in which I use vc-unaware tools and
> operate exactly as I would in any other portion of the file
> system, I must remember that I am in a vc-controlled context
> and use vc-aware mv/rename commands.  This is real a goatcha
> when one is furiously refactoring.
> 
> I would like to suggest that when one commits a sandbox in
> which both older files seem to have disappear and newer files
> have appeared the vc-system should offer the user a chance to
> identify delete/add pairs that actually represent mv/renames. 

One thing we can do fairly simply is allow people to do 'bzr mv' after
the fact.  If we change to giving an error when files are missing rather
than assuming they're deleted, then you can notice what's wrong and go
and 'bzr mv' to fix them up.

darcs has a clever way to do this which is that if the destination
working file already exists and the source doesn't then it assumes you
just want to fix up the inventory and not move the working files.
(Obviously this does not handle the case where people flip two files; in
that case they have to handle it some other way.0

> To be friendly to both scripts and interactive users I would
> suggest that the default should be the interactive prompting
> but that there should be both a --no-prompt-for-mv-or-rename
> and a --abort-if-possible-mv-or-rename flag.
> 
> I have a tougher time formulating a proposal for the logical
> generalization, namely being able to call out when a newly
> identified file did not spring into existence devoid of any
> prior history, but instead was carved out of an earlier file.
> But obviously I would love such functionality :-)

Identifying them has to fall back to some heuristic guided by the user.
You can look at inode numbers, common text, even filenames.

At any rate it is pretty easy for bzr to tell what files have gone
missing and what are unknown, and a script or plugin can take it from
there.

-- 
Martin

-------------- 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/20050412/7e01d377/attachment.pgp