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

Re: Merge tracking proposal, rev 2

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-05-12 18:52:49 CEST

Ben Collins-Sussman wrote:
> On 5/6/06, Daniel Berlin <dberlin@dberlin.org> wrote:
>> This is revision 2 of the proposal.
> So I finally locked myself in a small room for an hour today, and
> forced myself to read both the merge-tracking 'requirements' doc and
> your revision-2 proposal. I'm really impressed. It sort of feels
> like your proposal for storing merge-info has always been lurking in
> my subconscious, but you did the labor of pulling it out into a spec
> and proving that it's enough to build features on. Phew!
> Here are my requests:
> 1. Please put your design into notes/, so it can be improved on and
> version-controlled.


> 2. Please fix the typos, missing words, etc. And make the formatting
> prettier. :-)


> 3. Your proposal is all about storing 'mergefrom' info in versioned
> file and dir props. However, to really satisfy all of our future
> merge-tracking use-cases, we need to be storing 'mergeto' information
> as well, so that people can ask questions like, "which branches has
> this bugfix been ported to?".

You realize of course, that there is no need to record explicit
merged-to information in the fs to do this.
You can always answer this question with the current design, because
mergedto is just the path where the mergeinfo property is set and
contains a path corresponding to the one you are looking for.

It just requires possibly crawling the entire repository unless you
index it.

 After chatting with you in IRC, I now
> understand that you're planning to build some sort of server-side
> index that tracks *both* mergeto and mergefrom information, and is
> easily queryable via new FS and RA apis. Can you at least talk a
> little bit about this in your design proposal?

Sure, but the index schema is not currently a fixed one (I've changed it
a few times), nor is the method of indexing, which is currently a simple
sqlite database. (Which, btw, i tested under heavy simultaneous client
read and write loads over nfs on linux and solaris with no problems).

 People reading the doc
> need to know that the idea is present, and that it's being worked on.

Sure sure.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 12 18:54:30 2006

This is an archived mail posted to the Subversion Dev mailing list.