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

Re: Improving support for copy and move

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-05-19 16:49:22 CEST

rooneg@gmail.com wrote on 05/18/2006 08:24:46 PM:

> On 5/18/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 5/18/06, Paul Burba <paulb@softlanding.com> wrote:
> >
> > > As I said, my patch is, at best, only a partial solution...tests 4 &
> > > still fail when attempting the last of the three moves. I don't
want to
> > > proceed any further until some folks with more experience in this
> > > weigh in. I'm just going in circles at this point :-(
> > >
> > > Please take a look, thanks,
> >
> > I'm not a libsvn_wc guru, but I did take a look. The patch so far
> > seems pretty reasonable, but the reason it's not working at this point
> > is that svn_wc_get_ancestry is failing to return a copyfrom URL when
> > you move a file that's within a moved directory. It needs to get
> > smart enough to know that the file's inside a dir that's been moved,
> > so you have to go back to the previous location of the file to get its
> > source url. The error you end up seeing (about it not being in the
> > repository yet) is simply fallout because it can't find a source url,
> > and it knows that it should have one at that point).
> >
> > I'll look more closely and see if I can figure out a way to fix this,
> > but no promises, libsvn_wc is very much not my preferred area to play
> > around in ;-)
> Ok, here's an updated version of Paul's patch that includes enough
> magic to make move_file_within_moved_dir pass. The problem was that
> the contents of a directory that is moved are marked as copied, but
> don't have copyfrom urls. You need to catch this case, and if it
> happens climb back up to the parent dir of the src path and see if it
> has a copyfrom url, etc. I suspect something similar needs to be done
> for directories, which will make the last test pass, but I haven't
> looked into it yet.
> -garrett
> [[[
> Allow copy/move files that already copied.
> * subversion/libsvn_wc/copy.c:
> (copy_file_administratively, copy_dir_administratively): Use source's
> copyfrom-url and copyfrom-rev instead of url and rev when copying or
> moving already copied files or directories. When copying
> set the URL entry in the destination directories "this dir" entries
> record to the source's copyfrom-url, if there is one, otherwise climb
> up to their parent directory looking for one. XXX do this for
> copy_dir_administratively.
> * subversion/tests/cmdline/copy_tests.py
> (copy_copied_file_and_dir, move_copied_file_and_dir,
> move_moved_file_and_dir, move_file_within_moved_dir,
> move_dir_within_moved_dir): New tests.
> ]]]


Thanks for taking a look at this.

I found one problem with your patch that move_file_within_moved_dir didn't
test for: Moving a file within a moved directory where that file is not in
the root of the moved directory...

...Hmmm, not sure that made sense, if not, here's an example using the
good old pristine greek WC tree as a starting point:

svn mv A\D A\B\F\D_moved
svn mv A\B\F\D_moved\G\tau A\B\F\D_moved\G\tau_moved
svn: Unable to lock 'A\B\F\D_moved'

Problem is that svn_wc_copy2() calls copy_file_administratively() with the
svn_wc_adm_access_t *src_access for "A/B/F/D_moved/G". Your tweak in
copy_file_administratively() climbs up the WC tree and calls
svn_wc_adm_retrieve() looking for the entry for "A/B/F/D_moved" which
doesn't exist in src_access and causes the SVN_ERR_WC_NOT_LOCKED error.

I'm working on a fix based on your patch and expanding
move_file_within_moved_dir and move_dir_within_moved_dir to test this
scenario. In the meantime, any words of wisdom are appreciated.

Thanks again,

Paul B.

Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 19 16:50:04 2006

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