> From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
> There are two issues here: a) what the merge algorithm needs to work
> correctly, and b) what the *user* wants to know about merge history. And
> probably c) what's optimal.
> If a file did not change during a merge, then we don't have to record
> the merge source to satisfy a). We *might* want to record the merge
> source to satisfy b). And c) is a tricky issue, given how Subversion's
> storage model works.
Ok, that's not a bad way to look at it. Let me try to build on that.
First, let's write that a-b-c list a little differently, putting users
first:
x) What users want from merging.
y) What can be implemented, practically, in the context of svn.
z) What's the best way to satisfy the constraints (x) and (y).
> Imagine the following: [....]
> [conclusion: recording merge histories on noderev by noderev
> basis is too expensive unless only directly effected files
> record that history.]
Right. And the interesting things about looking at the relationship
between "whole project tree" merges and their relationship to business
rules and project managment is that:
1) Whole project tree merging is a good fit for reasonable business
rules/project mgt. People don't talk about "the GCC patch to
files so and so" -- they talk about "the [implicitly: whole tree]
patch to GCC that adds feature X or fixes bug Y".
2) Whole project tree merging doesn't need noderev by nodrev merge
history. It keeps one history record for all the files in a
project tree. It doesn't even require storing that history in
properties or other repository meta-data -- it has been
demonstrated that it can reasonably stored as plain old source
files -- an add-on to the project source tree.
I don't think there reasonably is a "the merge algorithm". I think
there are many merge algorithms, and that the best design strategy is
to syupport a big toolbox of many of them. Broadly, the algorithms
can be classified into "node by node" and "whole tree" -- and I think
that from the business rule/project mgt perspective, "whole tree" is
the priority. How convenient, then, that whole tree merging and merge
histories can be implemented without any changes to the db schema at
all and most likely, with less work and less destabilization.
It looks to me like the svn core developers are "stuck" with the false
assumption that smart, useful merging is necessarily node by node and
necessarily records history in noderev properties. Those
implementation ideas are being treated as design constraints. They
seem to stem from the underlying "project-less" structure of a svn
filesystem -- a structure that is already directly contradicted by the
recommended usage patterns.
I'm saying: forget about those false constraints. Consider
introducing a layer _over_ svn to define (a) project trees as first
class objects; (b) logical file identities within project trees (not
strictly related to node ids); (c) in-tree patch logs as a way to
record merge history. On top of those concepts, which require 0
changes to the db schema, and 0 use of properties, you can inherit
"for free" the toolbox of merge operators from arch -- plus a bunch of
other functionality besides.
To be sure, Sander's mechanisms look useful to me as a programmer
convenience -- as a way to manipulate individual files _within_
project trees. I pretty much wouldn't care if they ever applied to
tree-deltas -- I think their usefulness mostly pertains to individual
text files.
But the whole tree mechanisms look to me easier to implement, less
destabilizing, valuable for more than just merging, and more closely
aligned to the business rules/project mgt patterns in which fancy
merging is of the greatest interest. Alas, in saying that, I suppose
that I'm in some sense speaking more through you to collabnet than to
you directly.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 13 05:59:58 2003