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

Re: Merging record_exact_merge_and_commit_revs to /trunk

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-15 19:23:50 CET

On Dec 15, 2007 4:43 AM, Mark Phippard <markphip@gmail.com> wrote:
> On Dec 15, 2007 1:19 AM, David Glasser <glasser@davidglasser.net> wrote:
> > On Dec 14, 2007 8:45 PM, Kamesh Jayachandran <kamesh@collab.net> wrote:
> > > David,
> > >
> > > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133396 we have
> > > decided to port this schema change from issue-2897 branch.
> > >
> > > With this mergeinfo_changed schema change we have exact merge ranges for a
> > > given commit.
> > >
> > > The idea behind this change is to record *some information* which is very
> > > difficult to populate once we release without this schema change.
> >
> > I'm confused. Are you suggesting that the reason to merge the schema
> > change to trunk now (without the higher-level code that uses it) is so
> > that we can release 1.5 with the schema change but without any code
> > that uses it?
>
> The schema change captures mergeinfo that would be hard to go back and
> recreate in 1.6 if we do not start capturing it now. I suggested that
> Kamesh extract out the schema change and the code that populates the
> table so that we would have the OPTION of including it in 1.5 if his
> other work did not make it AND we concluded that this extra
> information was going to eventually be essential.

If we choose to ship 1.5 with sqlite, we will need to make major
changes to the indexing code whether or not the schema changes (Issue
3037). I have a plan to deal with 3037, and it's not *too* hard, but
it's not trivial either (it completely changes the interface between
the FS code and the sqlite code).

I am happy to do this (ie, fix 3037), but I don't want to put that
time in unless we're sure we really *do* want to keep sqlite in 1.5.
And I don't think we should do that unless we're sure we are actually
shipping with a feature that requires it. As I mentioned earlier in
this thread (or maybe it was another one), I think that we can support
the features from this branch without sqlite.

Given that, porting the schema change to trunk seems really premature.

(And I would be very very very against including a sqlite database in
1.5 just for the sake of gathering data that could theoretically be
used by 1.6. Our current experience with sqlite makes me conclude
that we don't yet have a solid idea of exactly what information we
need from sqlite; guessing at 1.5 time and getting it wrong is
pointless. Sure, this might mean that 1.6 might require a dump and
load, but better that we require "dump and load but get the right data
in the end" than "you don't have to dump and load, but the db isn't
actually useful".

--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
Received on Sat Dec 15 19:24:02 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.