On Tue, Mar 2, 2010 at 08:48, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Mar 02, 2010 at 07:53:30AM -0500, Greg Stein wrote:
>...
>> We do *not* record moves today.
>>
>> We *will* at some point in the future, which is most likely *after*
>> the 1.7 release.
>
> So the question of how exactly we'll trace moves is still up in the air?
>
> I've been pondering whether we should use a git-like approach of guessing
> moves at commit time based on content, rather than explicitly tracking
> what the user did. Recording tree refactorings explicitly is very
> complex and prone to failure. E.g. tracking directory replacements plus
> additional post-replace refactorings inside replaced directories is
> giving me headaches, and I have doubts that our current wc_db schema is
> up to this task. I'd rather like to avoid this complexity if possible.
> Since we'll have content checksums in the pristine store anyway, maybe
> using a lazy content-based guessing approach in addition to copyfrom
> info will be fine if we can figure out a way to make it track directory
> renames as well?
Oh no no no... the schema is fully set up to record moves properly,
without any guesswork. It is just that nobody will invoke the function
(in 1.7!) to do the recording.
I'm comfortable that the schema will work. Please feel free to analyze
it for holes. But you're looking at the 'moved_here' and 'moved_to'
columns. You're also going to want to learn about scan_addition() and
scan_deletion() in more detail.
Doing moves at commit time also implies you've updated the repository
to understand that, which is a completely separate problem. Not to
mention the editor interface between the WC and the RA layers.
Cheers,
-g
Received on 2010-03-02 22:40:18 CET