> From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
> Again, true in essence, but what we're discussing here is "the merge
> algorithm" that Sander proposed. :-)
Well, two related threads have bled together here. The question posed
to me was "How do we represent merge history" and in my reply, I
anticipated Sander's (then) upcoming proposal, but also pointed out an
alternative.
> ... 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; or (b) crawl over all the nodes of the tree and all the
changes that have been merged into those nodes and perform a fairly
complicated computation on the data yielded by that crawl.
> 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.
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); (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.
Finally: elsewhere you talk about the functional core of the svn data
model being unlikely to change anytime soon. 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.
> 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.
>> 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?
On the contrary: CollabNet fosters a public svn community presumably
because they believe there to be a mutually beneficial alignment of
interests between the goals of serving CollabNet's markets, and
serving the interests of the public. On the basis of that presumed
shared interest, CollabNet is of generous intent towards the community
-- and I think it makes sense to return the favor. [The alternative,
cynical interpretation is one I have explicitly avoided here -- mostly
because I don't _think_ it reflects anyone's _intensions_, though I'd
caution that vigilence against effects that are most consistent with
the cynical interpretation is the constant obligation of everyone
involved. Consequently, ruling CollabNet's business interests to be a
taboo topic is extraordinarily inappropriate.]
I am hardly "well connected" in the world of consumers for revision
control systems, but I have had some interesting communications in
that market, and some interesting mentorship in the area of commercial
source mgt. generally. I feel that I have at least non-0
qualification to speak up, for the benefit of all parties, not least
CollabNet, when I see a design process that is teetering on the brink
of gah-gah land.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 14 02:13:39 2003