On Mon, Sep 23, 2013 at 9:49 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> 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
It's easy to drop the "from_root" parameter and
currently, it has to refer to the base revision.
However, it might be simpler to allow for the
commit editor to simply specify any old revision
as the source and let the server check whether
it is "out of date" (path moved or deleted since
the specified revision).
> 2. Could you please add at least several smoke tests for FS layer.
Yes, that's still a TODO.
3. Do we need format bump? How old FS format repositories will handle
There will be a format bump this week when
the log-addressing branch gets merged.
Yes, I think we should make move() support
contingent on the repo format. The backward
compat. variant would be the same as for BDB,
i.e. storing a simple ADD-with-history.
Received on 2013-09-23 11:35:00 CEST