In an incredibly long, mixed-topic post, Tom Lord wrote:
>* On Merge Histories and Project Management
>
[...]
> Brane asserts that in Sander's proposal, a directory (presumably the
> top level directory of a project tree) will have a merge history
> that is representative of the project tree as a whole:
>
> Brane ("B"):
>
> B> Any directory can serve as such a node. Even when they're
> B> not explicitly modified by a commit, every commit creates a
> B> new version of the directories that contain the changed
> B> files, all the way to the root, because of the "bubble-up"
> B> rule. These directories will be included in every merge.
>
> Of course, Sander hasn't spelled out his tree-delta rules, so we
> have to reason about the design space for them.
>
> You, Brane, seem to be saying that if any of the nested contents of
> a directory are modified by a merge originating in a different
> directory, even if the node_id/copy_id contents of the directory are
> not themselves altered, that the directory will acquire the
> necessary change records.
>
That's not quite what I said. The directory gets a new revision, yes,
but that doesn't mean that prop values (or rather, the svn:merged
records) bubble up the tree.
> There are two significant problems with that supposition.
>
> First, a merge to some nested part of a directory may be only a
> partial merge of the changes associated with a particular range of
> repository revisions on the merged-from branch. It is an expensive
> and tricky computation to figure out whether a given merge is
> complete or partial. Thus, when the merge history "bubbles up",
>
The merge history does not "bubble up". As I said, the directory gets a
new version, and the merge record for that directory can be attached there.
> what should the containing directory record? There is no mechanism
> in Sander's proposal for recording "part of the nested contents of
> this directory have been merged; other parts haven't".
> Additionally, just deciding whether it was a partial or complete
> merge hasn't been addressed.
>
Of course there is. Imagine the following layout:
.../project/main (the mainline)
.../project/branch (the branch, copied from /project1/main
Now, imagine that you have a working copy that contains the mainline,
created thusly:
$ svn co uri://.../project/main sandbox
Now, when I merge from "branch" to "main", even if it's a partial merge:
$ cd sandbox;
$ svn merge -r13:17 url://...project/branch .
"main" will acquire a merge record (":13-17:.../project/branch"
according to the current proposal"), assuming we always add merge
records to directories even if they're not modified. Of course, that
record doesn't tell you the details of what happened to the various
nodes below "main", but it doesn't have to -- that information is both
recorded in the tree and reproducible by other means, simply by looking
at the repos history. Apart from that, I think that's exactly the
information you want.
(Maybe you'd prefer to record it in .../project, rather than
.../project/main, but I don't believe you'd gain anything by that.)
> Second, since repositories are free-form, and the top-level
> directory layout "just a recommendation", let's suppose that instead
> of making "/branches", I make "/branches/division1" and
> "/branches/division2" where division1 and division2 are two parts of
> my development organization. Furthermore, let's suppose that I'm
> storing 15 or 20 projects in this repository rather than just one.
> If records "bubble up", as you propose, then the merge histories for
> "/branches/division[12]" are going to be both huge and largely
> useless.
>
Since what you describe is not what would happen (presumaby, each
division would only use its own branches), that's not a problem.
> So I think that, in the design space for how to handle tree-delta
> merge histories, the only practical option is to not bubble up --
> but to modify directory node histories only when the
> name/node_id/copy_id contents of a directory change. And in that
> case, as I said, there is no merge history that reliably records the
> history of a project tree; to compute the merge history of a
> project tree will be both expensive and tricky.
>
You still didn't explain exactly what you mean by "merge history of a
project tree". If it's something different from what I (and Greg Hudson,
apparently) are talking about, then it'd be a good idea if you explained
what you mean.
> Greg offers this twist:
>
> Greg Hudson ("GH"):
>
> GH> Merge records don't bubble up, but changes do. So any
> GH> merge done from the top level of a project will involve
> GH> changing the root directory of the project, and therefore
> GH> adding a merge record to that directory. Or so I would
> GH> expect, anyway. (Just like the "file that changes with
> GH> every merge" which you suggested as a workaround
> GH> previously.)
>
> I think your expectation is either incorrect or involves UI
> incoherence.
>
> The "change to the project root" is not necessarily anything more
> than a change to the revision numbers of its name:node_id.copy_id
> contents. Similar changes are made to each parent directory of the
> root. So if such changes trigger merge-history updates, then all
> parent directories up to the root are similarly effected, and the
> problems I described above still apply. But that would be "bubbling
> up" and you said "merge records don't bubble up" so:
>
> I assume that you mean, then, that the directory named in the
> arguments to `merge' gets an updated merge-history if any nested
> contents of that directory are modified by the merge. Yet this
> approach is ultimately UI-incoherent for at least two reasons.
> First, it invites the user error of performing a complete merge in
> the effected subtrees, yet failing to have that noted for the
> project tree. Second, it invites the user error of committing
> effected subtrees but never committing the project tree directory.
>
Why is that a user error?
> (So, on those two points, there is yet again a dissonance between
> the "policy free" nature of the storage manager an the "project
> tree" orientation of sane practices -- so, as elsewhere, I say it
> makes sense to treat storage mgt and rev ctl as layers, project
> trees as first class objects in the rev ctl layer, and to move to a
> UI that reflects the rev ctl abstractions rather than the storage
> manager abstractions).
>
What you're describing would effectively (a) forbid people from checking
out or checking in anything but the whole "project tree" (or at least a
whole branch) at a time, and (b) impose a rigid structure on the format
of the repository. But that's not acceptable -- projects are composites,
and the directory structure usually reflects the component structure.
You might say that each directory represents a logical
"sub-project-tree". It is entirely valid to operate on these smaller
components, assuming that such operations are in line with project policy.
There are many, many different kinds of project policies, and any tool
that tries to impose a particular one will never be useful for the
majority of software projects out there. Therefore, adding this kind of
restriction to Subversion is unacceptable.
--
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 Tue Apr 15 02:06:25 2003