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

Re: merge tracking use cases

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-01 03:42:38 CET

On Nov 30, 2007 5:26 PM, Blair Zajac <blair@orcaware.com> wrote:
> I'm using the Subversion repository just as a versioned filesystem and don't
> care about having svn_fs_copy() and svn_fs_delete_node() managing merge info, in
> fact, for performance, I would rather not see it do that work at all in my
> application.
> If we go down this route, can we have new versions of these methods that do no
> merge tracking, say svn_fs_copy_no_merginfo() or something clumsy like that and
> the new svn_fs_copy() calls svn_fs_copy_no_merginfo() then does the mering work?

So, the entire design for merge tracking right now is based on the
data being stored in svn:mergeinfo props in the normal filesystem in
the repository. (The design was never for the sqlite to be anything
more than a redundant index for efficient queries.)

What you're suggesting is changing that: to have mergeinfo be a
fundamentally different kind of data for an svn node prop.

I'm not saying this is right or wrong... but it's a huge change in the
entire concept of svn merge tracking, not something we can patch up
without major changes, I think.


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 03:42:56 2007

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.