On Nov 30, 2007 2:16 PM, Blair Zajac <blair@orcaware.com> wrote:
> Ben Collins-Sussman wrote:
> > As an outsider, I think nobody will flinch one bit if 'svn log' or
> > 'svn blame' aren't merge-sensitive just yet. But not being able to
> > handle feature branches? That's the single biggest use-case we have.
> > It's what most users currently use 'svn merge' for. It's the
> > scenario that the svnbook takes pages to explain, going into horrible
> > detail trying to teach users how to manually track revision sumbers to
> > get the task done. If "basic merge tracking" can't take away this
> > famous pain, what actual benefit is it bringing to users?
> >
> > I'm going to have a really hard time saying to people, "Oh hey, you
> > can now repeatedly merge trunk to your branch now without tracking
> > revisions manually. But, um, when you merge back, you better get the
> > -rX:Y argument just right." It doesn't feel like very much progress.
> > I define "success" as "the user never needs to type a revnum".
>
> +1 on this. We need to at least have this svnmerge.py capability in 1.5. I'd
> rather see 1.5 delayed and get this feature in then ship early, i.e. pull a
> Blizzard.
I agree, although I also think that log -g is a "must-have" feature too.
It is not clear to me that either of these things are going to mean a
massive delay for 1.5. That being said, as frustrated as everyone is
waiting for 1.5, I think we will actually lose a lot of users if the
first merge tracking feature we ship is not pretty damn good and
complete.
glasser thinks he knows how to solve the log -g problems. He just has
some reasons he thinks it should wait. Kamesh seems to think he can
fix the reflective merge problem. The biggest problem is that no one
seems to really understand the exact approach he is taking, and more
importantly, if glasser completely removes the usage of SQLite, can
Kamesh still implement his solution? I seem to recall that Kamesh
mainly needed to know what revisions were actually merged when a merge
occurs. The diff of the mergeinfo gives you that, but it could also
contain some changes to the mergeinfo that came with the merge? My
point is that it might be possible for Kamesh to get that info without
SQLite.
Anyway, I still think we should look for solutions to the problems
before we decide to remove them and ship. I think it would be a
disaster for us if we do.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 20:27:08 2007