[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

renames/moves in wc-ng (was: (Re: [PATCH] wc-ng - Remove use of entry_t from) calculate_target_mergeinfo

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 2 Mar 2010 14:48:16 +0100

On Tue, Mar 02, 2010 at 07:53:30AM -0500, Greg Stein wrote:
> On Tue, Mar 2, 2010 at 07:42, Philip Martin <philip.martin_at_wandisco.com> wrote:
> > Greg Stein <gstein_at_gmail.com> writes:
> >
> >> Thus, the notion of moved_here is not all that relevant because I
> >> would hope this function won't survive to the point where we start
> >> recording moves in wc_db (so, thus, we'll never record/generate that
> >> status).
> >
> > I don't understand that paragraph.  Do we record moves now?  Are we
> > going to record moves in the future?  You seem to imply that we will
> > in future record moves and simultaneously that we won't generate a
> > svn_wc__db_status_moved_here.  It doesn't really seem to make sense.
>
> 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?

Stefan
Received on 2010-03-02 14:49:16 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.