[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: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 23 Sep 2013 11:49:10 +0400

On 23 September 2013 02:51, Stefan Fuhrmann
<stefan.fuhrmann_at_wandisco.com> wrote:
>
> Hi there,
>
> As of r1525442, there is a new svn_fs_move() API supported
> by all backends with BDB providing only rudimentary support.
>
> It turned out that move() should not implicitly issue a delete()
> on the source node as this creates all kinds of ordering issues
> and, worse, makes it hard to verify incoming changes. Instead,
> just call move() as you would call copy() today and issue an
> explicit delete() for the source path.
>
> 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.
>
Hi, Stefan. Several questions/notes:
1. Why svn_fs_move() accepts two svn_fs_root_t objects? I thought that
original plan was to accept only TXN root, since moving is supported
only from base revision. Or we're going to support 'resurrecting' move
operation?

2. Could you please add at least several smoke tests for FS layer.

3. Do we need format bump? How old FS format repositories will handle
svn_fs_move()?

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-09-23 09:50:07 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.