"Mark Phippard" <firstname.lastname@example.org> writes:
> I was updating Jack Repenning on all of this to get his take. He said
> that #2897 is the most common use case. It is what everyone that uses
> ClearCase UCM does (in fact it is officially called the "Standard Use
> Model") and if Subversion does not have that feature then it does not
> have merge tracking.
> I cannot really disagree. I raised this back in June and I've raised
> it several times since then. It is hard to argue that we have
> advanced the bar if a user cannot merge a branch back to trunk.
I'm sorry I can't participate fully in these discussions today; just
had some other stuff booked already.
I do want to point out, though, that David Glasser's work on
eliminating sqlite usage is still valuable *even* if we ship with an
sqlite dependency in 1.5 (for issue #2897).
First, minimizing our use of sqlite is still good, in terms of
reducing complexity. And second, no rule says we can't lose a
dependency in a future release. If we solve #2897 using sqlite now,
and later learn how to solve it without sqlite, that's okay -- we're
allowed to drop sqlite as a dependency later. I'm not saying that's
the ideal route, of course, but it's a route.
What we DO need is to agree on what *user-level* set of features are
Must Ships. Personally, I think.
1. 'svn merge' (with no further arguments) Does The Right Thing
whenever possible. At least it should DTRT on a feature branch,
and if we have to think imaginatively to figure out what it
should do (or how it should do it) under other circumstances,
then let's get thinking. There's another thread about this
going on, started by cmpilato, so please follow up there.
2. Merging back to branch-source should choose the "right" set of
revisions to merge (this is issue #2897). But, it is *not*
necessary in 1.5 to avoid the user redoing conflict resolution
work. While that would be nice, it's okay to defer it to 1.6.
We need to agree on that list, and then see where we are. The last
few days, we've suddenly all gotten different ideas about what the
feature set is. That's bad; no one can figure out whether their work
will or will not be in 1.5. (I'm exaggerating a bit, but the problem
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Dec 1 00:32:52 2007