Tom Lord wrote:
> > From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
>
> > ... whole-tree merge history would be recorded in exactly the
> > same way as file merge history -- in svn:merged properties on
> > directories.
>
>Yet, under Sander's proposal (making reasonable assumptions about how
>he fleshes out tree-deltas), there is _no_ directory in a project tree
>that reliably records the merge history of that project tree. To
>compute the merge history for the tree, it's necessary to either: (a)
>ensure, by usage pattern, the existence of a node that is reliably
>modified in every revision, on every branch, and included in every
>merge -- then rely on the history of that file to be representative of
>the tree;
>
Any directory can serve as such a node. Even when they're not explicitly
modified by a commit, every commit creates a new version of the
directories that contain the changed files, all the way to the root,
because of the "bubble-up" rule. These directories will be included in
every merge.
> > No, it's the other way around: Subversion's design is being treated as
> > an implementation constraint. Sander's proposal may not have mentioned
> > this explicitly, but getting reasonable behaviour on whole-tree merges
> > is *exactly* what it's aiming at. The assumption is that the merge
> > algorithm, as described for files, can be logically expanded to apply to
> > tree merges (rearrangements). Up till now, I haven't seen any evidence
> > to the contrary.
>
>I see at least three problems.
>
>One is the practical "project tree history" problem mentioned above.
>
If a project tree is nothing but a collection of branches (directories),
then there is no problem.
>Another is that, while you elsewhere assert that the node_id is the
>logical identity of a file within a project tree, (a) there is nothing
>to prevent my winding up with multiple files in a project tree that
>share a common node_id (and, indeed, plausible scenarios where this
>would occur quite by accident);
>
Sure, two files in a tree can have the same node id. So what? That just
means they're related; in fact, that they are different branches of the
same file (they'll always have different branch IDs). That's something
you have to know; after all, a tree merge is composed of node merges.
>(b) you've now added the constraint
>that users must explicitly manage node_id's with logical file identity
>in mind -- which means that the easiest way to make some change just
>editting the tree is not going resemble the correct way to make that
>change using svn.
>
I don't see it that way. There's no reason at all to expose the node IDs
in to users in any way. Managing node IDs is the FS layer's job. Users
only have to think in terms of files and directories, nothing else.
>Finally: elsewhere you talk about the functional core of the svn data
>model being unlikely to change anytime soon.
>
IIRC, I said that about the usage model. The two are connected, but the
usage model drives that data model, IMHO.
> Well, the more that you
>make dependent on that model, the fewer degrees of freedom there are
>to _ever_ change it. It's the classic design question of "monolith"
>vs. "software tools". There's no good reason to make merge history a
>part of the monolith when it can, in a practical manner, be made
>orthogonal.
>
I've said before that, as far as I can see, the representations are
functionally identical. I've also said that storing the history in the
tree is better from the point of view of Subversion's usage model. You
haven't even tried to show me why your way is better (except with such
arguments as the above, and the "layer on top of svn" approach). So, I
don't buy it.
> > All I can say here is, again, that Sander's proposed mechanism
> > does exactly what you want on the tree level, it just doesn't
> > have shape and colour that you'd like.
>
>Except that in saying that, you would be inaccurate.
>
You keep saying I'm wrong, yet you don't say how or why. You keep
throwing around phrases like "project tree history", yet you don't say
what a project tree is (I've beem making assumptions about that; i.e.,
that a "project tree" is any subtree that is by convention treated as a
whole).
Another thing strikes me: On the one hand, you complain that the
proposed data representation is too monolithic; on the other hand, you
want to impose a constraint (project trees) on the data model that would
make it less flexible.
Indeed, Subversion's data model relies heavily on conventions:
Organizing the tree into projects, branches, etc. -- and consequently,
merging rules -- are all a matter of convention. That's not a bad thing
at all -- in fact, I consider that Subversion's strongest feature.
> >> Alas, in saying that, I suppose that I'm in some sense speaking
> >> more through you to collabnet than to you directly.
>
> > Tom, you're backsliding again. :-) Let's leave CollabNet's
> > commercial interests out of this.
>
>Excuse me?
>
>First, I don't find that funny and so I don't understand your ":-)".
>
>Second, are you saying that "CollabNet's commercial interests" do not
>have a significant impact on those core developers who are employed by
>svn or that they do not, in turn, have significant impact on the plans
>for and design of svn?
>
This is a discussion about the design and data representation for a
better merge algorithm. So let's talk about design, and leave politics
out of it. Please.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 14 17:34:50 2003