[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: Blair Zajac <blair_at_orcaware.com>
Date: 2007-12-01 04:48:27 CET

David Glasser wrote:
> 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.

How is that? I was just thinking that the work to update the svn:mergeinfo
property on a node would not be done.

Let me know if I misunderstanding something.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 04:49:01 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.