Re: merge tracking use cases

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.

--dave

-- 
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