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

Re: [RFC] Altering copyfrom information in repository

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 22 Nov 2011 08:57:21 -0500

On 11/22/2011 02:26 AM, Daniel Shahaf wrote:
> On Tuesday, November 22, 2011 12:23 AM, "Johan Corveleyn" <jcorvel_at_gmail.com> wrote:
>> Hi all,
>>
>> I'm wondering if it would be feasible to (make it possible to)
>> alter/add copyfrom information in an SVN repository. And if so, would
>> this be a desirable feature?
>
> It's not feasible for FSFS without a format bump and a new layer of
> code. I believe trivial for BDB though.

I'm not convinced that it's "trivial".

The filesystem backends expect that a node which was copied has the same
node-id (a portion of the large node-revision-id) as its copy source, and
that a file added *without* history gets a new unique node-id. These
node-ids are used for ancestry checks. To do a post-facto copy operation
means, at a minimum, reassigning the node-revision-ids for the copied item
and all of its successors, patching up the nodes themselves to point to the
right successors, patching up their parent directories to point to the new
node-revision-ids, etc.

Further, a copy event within the repository changes the way that
node-revision-id's are incremented when cloned (that is, when new versions
of the items are created), which is somewhat tricky for clone children of
copied directories. Adherence to that algorithm is (again) a critical part
of the historical accounting and traceability within the FS logic.

I'm not saying that we shouldn't seek to add this rectification mechanism.
I merely want folks to understand the likely scope of the change.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-11-22 14:57:58 CET

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.