On Nov 29, 2007 5:45 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> "David Glasser" <glasser@davidglasser.net> writes:
> > When working on 1.6, we can solve #2897 and fix "log -g" with much
> > more leisure to get it right. If fixing them requires retrying the
> > sqlite index again, or my metadata idea, then so be it: we can add
> > that code back in in 1.6 (it's all in version control) and make it
> > work for those needs then.
> >
> > But I think we can make 1.5 much more solid and less complex by simply
> > deferring #2897 and "log -g" to 1.6. 1.5 will still have a superset
> > of svnmerge.py's features.
> >
> > (I don't mean to disrespect the hard work done on the sqlite backend,
> > "log -g", or issue-2897 here. I just think that these are difficult
> > problems to solve, and that making a release that doesn't try to solve
> > them and fixing them with more leisure is better than trying to do
> > everything at once and being full of bugs.)
>
> I'm not opposed to your idea, and definitely like the idea of getting
> 1.5 out sooner. But we need to know what user-visible behaviors will
> not be in 1.5 (that we expected to be in 1.5) if we do this. Is it
> just
>
> 1. no 'svn log -g'
> 2. issue 2897 is not resolved (which is a big deal!)
>
> ? Or are there other places where behaviors will change?
To the best of my understanding, there is only one place in the code
where queries are made of the mergeinfo database that are more
sophisticated than "what is the svn:mergeinfo property for path P at
revision R".
It is only accessible outside libsvn_fs from svn_fs_get_mereginfo_for_tree
... which is only accessible at the REPOS layer from
svn_repos_get_logs4 with the include_merged_revisions flag set
... which is only accessible at the RA layer from svn_ra_get_log2 with
the include_merged_revisions flag set
... which is only accessible at the CLIENT layer from svn_client_log4
with the include_merged_revisions flag set
... which is only used by our clients by "svn log -g".
> Would users
> have to specify URLs where we had thought they wouldn't, ever? (I
> realize, after our IRC conversation today, that that might happen for
> unrelated reasons, but if we do decide to go with URL-less merges
> where possible, will your proposal make that harder?)
I don't know the answer to this question, but I don't believe it is at
all related to this issue. There are lots of things going on in
merge-tracking land; I don't believe this one affects the backend,
unless solving it requires a significantly different sort of query
from the ones we are making now.
> We'd need to carefully present it as "Subversion 1.5 with Stage 1 of
> merge-tracking support. Stage 2 to come in 1.6; etc." And we'd need
> to precisely define what "Stage 1" means, so users aren't
> disappointed.
Yes. But again, the only reason "log -g" is a 1.5 feature now is that
Hyrum rocks and finished a 1.6 feature early than originally planned.
--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 Fri Nov 30 03:58:05 2007