refactoring and noting mv/rename after the fact

[John Yates]

This is totally half-baked so as soon as anyone points up the
slightest flaw I will disavow any connection to the idea... :-)

Given that a function like CVS annotate can associate with each
line of a file the most recent commit that affected that line
one can formulate annotation closure for a given line.  This
would be that set of commits that affected that line since the
inception of history.

Now if one could identify that set of line in one or more pre-
existing files which were used to cobble together some new file
then the union of the commits in the closure for each copied
line would represent the "interesting" sub-set of the history
of the earlier files that one would want to associate with this
new file.

(A little voice in my head suggests that there must be SOME
relationship between this concept and Codeville's dependence
on knowing the origin of each line in a merge.)

As I suggested originally, I do not know how to take that
intuitive picture further to a concrete suggestion.

/john

> -----Original Message-----
> From: bazaar-ng-bounces at lists.canonical.com
> [mailto:bazaar-ng-bounces at lists.canonical.com]On Behalf Of luna
> Sent: Tuesday, April 12, 2005 12:11 PM
> To: Bazaar-Ng (E-mail)
> Subject: Re: refactoring and noting mv/rename after the fact
> 
> 
> John Yates a écrit :
> 
>>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 :-)
> 
> 
> some support of 'copy' in versionnig system, that would be nice, I think 
> so.
> It will not replace the 'mv' functionality but it could be interesting 
> to have some historical log for such files.
> 
> What do you think about that ?