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".
What I'd like to understand is: how does this new sqlite-less design
(which sounds great!) actually relate to the various solutions we've
discussed for issue 2897? Is sqlite really required to subtract one
patch from another patch?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 04:07:36 2007