[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-12-15 20:27:35 CET

On Dec 15, 2007 1:23 PM, David Glasser <glasser@davidglasser.net> wrote:
> 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".

Let's be clear what this "new" information is. I think that it is
essentially the information that Folker has been mentioning and that
is, what were the exact revisions/paths that were merged in this
commit. The mergeinfo property contains the information, but it also
contains other changes to the property, such as the values of the
property that came with the merge. Plus elision might also change the
property. Except in the simplest cases, a diff of the property does
not yield this information.

I still do not believe this information is impacted by the deep
copy/delete operation (issue 3037) because this is only
"transactional" information. It does not need to be copied or
deleted. That being said, I wonder if we couldn't actually just store
this information in a revision property?

It seems like the log -g code could also use this information. I
actually wonder how the code could work correctly without it? Perhaps
the log -g code is actually doing the work of figuring this
information out after the fact.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 15 20:27:45 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.