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

Question on copies implementation

From: Andrea Aime <aaime_at_openplans.org>
Date: 2006-11-08 17:15:35 CET

Hi all,
I'm trying to design a versioning system for spatial data
held in a database (if you're curious, see here:
http://docs.codehaus.org/display/GEOS/Versioning+WFS),
and I have a question after reading the design doc at:

http://subversion.tigris.org/design.html

One thing I'm sure I do not understand is the relation
between diffs and branches.
On the diff section you say that you store reverse
diffs and only the latest revision is a full copy.

Moreover, on the branch/tag sample the cheap copy
is defined as a simple pointer to the previous revision.

Let's say I do open a branch, and there's a file A.
Now I do modify it in the branch, going to revision N.
Does this mean that the full text version of the file
is now attached to the branch only, and to get to the
trunk version I do have to perform a reverse diff?
And the same goes if the same file is afterwards modified
on trunk? The full version is now attached to trunk, and
a reverse diff has to be performed to get to the
branch, and so on?

This is really scary on a versioned database point of view,
because this means I would have to keep the list of all
revisions making a branch into a table, and perform a giant
select xxx from versioned_table where version_id in (select * from
version_id where branch = "mybranch")....

Any suggestions on how to handle this on a database with
millions of records (each of which must be thougth as a "file"
if we do a comparison with svn)?

Cheers
Andrea

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 8 17:16:23 2006

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.