On Tue, Mar 02, 2010 at 07:53:30AM -0500, Greg Stein wrote: > On Tue, Mar 2, 2010 at 07:42, Philip Martin <philip.mar...@wandisco.com> > wrote: > > Greg Stein <gst...@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
