refactoring and noting mv/rename after the fact

[Daniel Phillips]

On Monday 11 April 2005 13:19, 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.

See the previous discussing with respect to "stat" and warming the dcache.  
Martin hates this too, as do I and others, so if I may paraphrase the result 
of the discussion: bzr-ng will know automagically about every little change 
you make to a working copy, no matter whether you go through bzr-ng to make 
it or bypass bzr-ng via patch, editor or unix shell commands.  For now, 
bzr-ng will rely on a simple stat strategy to implement this.  This has 
already been demonstrated (numerous times) to be acceptably efficient.  
Later, some high tech solution like inotify will be adopted so that bzr-ng's 
omniscience is only automagic but instantaneous.

Does that address your concern?

> 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.
>
> 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.

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".

> 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 :-)

"Me too".

Regards,

Daniel