"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? 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?)
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 02:45:37 2007