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

Re: Initial Move Support in /trunk now

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 23 Sep 2013 14:40:54 +0100 (BST)

Stefan Fuhrmann wrote:
> As of r1525442, there is a new svn_fs_move() API supported
> by all backends with BDB providing only rudimentary support.

Cool!  Thanks for starting the implementation, Stefan.

> It turned out that move() should not implicitly issue a delete()
> on the source node as this creates all kinds of ordering issues

Well, we know that ordering of moves is a tricky issue.

> and, worse, makes it hard to verify incoming changes.

I don't understand what you mean there.

> Instead, just call move() as you would call copy() today and
> issue an explicit delete() for the source path.

OK, so the API is currently structured the same as copy-and-delete except the copy part is explicit designated as a "move".  Fair enough, for now.

> As of r1525467, there 'svn log' now supports all moves across
> all RA layers and introduces a new "--auto-moves" option that
> reports many of the legacy DEL/ADD pairs as DEL/MOVE now.
> Since the actual implementation of that mapping logic is in the
> svn_repos layer, other functions may use this feature as well
> in the future.


> Currently, 'svn log --stop-on-copy" does not follow moves, yet
> but instead stops at moves just like on any copy.


- Julian
Received on 2013-09-23 15:44:22 CEST

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.