Julian Foad wrote on Mon, Apr 27, 2015 at 20:58:34 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote:
> >> On 17 April 2015, Daniel Shahaf wrote:
...
> > By the way, what's the relation between the "move tracking" part of the
> > work and the "first-class branches" part? I think move-tracking is the
> > goal and first-class branches were recognized as a dependency — as
> > something that must be in place for move tracking to be possible — but
> > I'm not completely sure that's the case.
>
> Originally I was working on merging; then realized we need a proper
> move tracking model in order to ever be able to merge moves well; then
> realized that properly distinguishing branches is essential to
> predictable move tracking. Completing the circle: merging depends on
> ... depends on branching. Oh... :-)
>
> The ultimate goal is good *merging*, in the presence of moves and renames.
>
Thanks, this helps to see the big picture.
> > So it sounds like you want the data model to a first-class "This is
> > a branch" concept.
>
> Yes.
>
> > Not sure where that metadata belongs: is it a node [not node-rev]
> > attribute? Is it an attribute of a copy operation [...]
>
> Think of branching as an additional dimension, orthogonal to
> 'elements' and 'plain copying'. ('Plain copying' is the kind of
> copying that's left after branching, merging, and resurrecting have
> all taken their rightful places in the new model.) As such, while it
> might be *possible* to represent branching by attaching metadata to
> existing (old system) objects, that's unlikely to be a satisfactory
> way.
>
Sure, the implementation may be completely different.
> > I suppose the answer depends on the properties, i.e., "interface", of
> > a branch operation. For example, is a copy of a branch a branch? (In
> > English: is 'bar' a branch after 'branch trunk foo; cp foo bar'? If it
> > is a branch, is its ancestor 'trunk' or 'foo'?)
>
> Although branches are "exposed" in Subversion by attaching them to
> paths, think of that like "mounting" a Unix file system on a path for
> the convenience of being able to address it through the existing
> addressing scheme (that is, paths, in both Unix and in Subversion).
>
> Food for thought. Thanks. (I'm still working on exactly how 'plain
> copying' fits in to the model.)
Okay. So what you're saying so far is that the data model will have
distinct concepts for "copying" and "branching". Presumably both cases
will result in the new object's delta chain pointing to the old object's
(this would be an implementation detail), but some high-level operations
will behave differently if the object operated upon is a branch compared
to if it is a plain copy. The interesting question is what those
differences will be.
Should "branching" be an atomic concept of the model, or a derived one?
That is, we could define "branch" as "a node created from an existing
node via the 'svnmover branch' API", or we could define branch in terms
of lower-level operations?
An example of the latter would be to define branching as "a node Y is
a branch of node X if X is a copy-wise ancestor of Y and there has been
at least one merge between X and Y, in either direction".
Daniel
Received on 2015-04-30 00:25:13 CEST