Sander:
> I just love quoting out of context...
Not my intent, obviously.
> Seriously, I meant to keep the proposal simple.
That's part of my point: there's tons more to do just to specify your
proposal or even to just finish working it out, while there's over a
year's experience running an implementation of mine (albeit on a
different storage manager -- and it's worth considering how much
difference that storage manager difference makes (not much, imo)).
To name just one example, your proposal relies heavily on variance
adjusted patching and, as much as you say it will be trivial to refine
the algorithm to eliminate any purported dangers, the fact remains
that it's all just untried theory at this point, with lots of design
and coding to do before it can even be experimented with in practice.
For cherry picking there is clearly a solution. The means to
record the data for it is already in the proposal. The same
goes for out of tree, or unrelated tree merging (although I
need to work that out I do have something on my desk for
that).
Yes, cherry picking can be solved and your meta-data looks (from quick
examination) rich enough to do the job. That's not the point:
cherry-picking has already been implemented on the mechanisms I'm
advocating. Useful areas of functionality have already been worked
out, implemented, deployed, and used.
But I don't mean to turn this into a fight about which of these two
mechanisms should be part of svn and which shouldn't. As I said: they
do different (but related) things -- they are essentially
complementary.
I only mean to point out there exists a potentially practical route to
get very useful history-sensitive merging into svn quickly, and that
taking that route has some interesting side effects such as doing a
lot of the grunt work needed to support distributed branching and
changeset-oriented auditing -- and that none of that requires deep
changes to svn, just (mostly) a new layer.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 00:28:23 2003