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

Re: [merge-tracking] points of improvement in mergetracking sqlite db design

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-08-31 02:11:06 CEST

On 8/30/06, Kamesh Jayachandran <kamesh@collab.net> wrote:
> Daniel Berlin wrote:
> > On 8/30/06, Kamesh Jayachandran <kamesh@collab.net> wrote:
> >> Hi All,
> >> I have the following points of improvements to mergeinfo sqlite db
> >> schema.
> >>
> >> 1. There is a duplicate info in the form of 'mergeinfo_changed.path' and
> >> 'N' records of 'mergeinfo.mergedto'. Where 'N' is the number of
> >> merges as
> >> of this commit on the path. This leads to arithmetic series kind of
> >> records
> >> in 'mergeinfo' upon each commit.(I have a working patch for this
> >> normalization but would like my other patches to find its way before
> >> posting this one.)
> >>
> >> 2. Currently we track 'mergedfrom', 'mergedto' paths in the sqlite db.
> >> This is not correct, rather we should maintain 'nodeid' and 'copyid'
> >
> > Actually, this is wrong. You can use the paths just fine.
> What if I delete /my_merged_to_path and recreate?
> The earlier merge history no more applicable for /my_merged_to_path.

Yes, so?
when you delete it, you will get a property delete, and we will mark
the megreinfo as having changed in that revision, with a now empty

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 31 02:11:59 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.