[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnmover feedback

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 27 Apr 2015 20:58:34 +0100

Responding on-list to some feedback Daniel gave off-list (quoted with
his permission).

Daniel Shahaf wrote:
> Julian Foad wrote:
>> On 17 April 2015, Daniel Shahaf wrote:
>>
>>> 0. As I said on IRC, even before diving into the implementation, I think
>>> it's more important to document the problem being tackled, and to have
>>> easy-to-use documentation. A single canonical document would be easier
>>> to use than scattered list threads and logged IRC discussions. Or
>>> a header file would do, assuming it documented the 1000-mile-high view
>>> and not just the particular interfaces and structures.
>>>
>>> Here are a few questions I think the docs should answer:
>>>
>>> - What feature is being worked on? How would you describe it to
>>> a developer? To a Subversion user? What's its use-case?
>>> It is clear that feature is about moves and branches in some way.
>>> What exactly about moves and branches is the branch about?
>>>
>>> UPDATE: the BRANCH-README update you made today answers that question,
>>> IMO: the answer is "Implement move tracking as would be expected by
>>> an SCM-concepts-aware user".ยน
>>>
>>> - What are "element", "branch" (in context of the move-tracking-2
>>> branch, pun not intended), "branch sibling", "branch instance", etc?
>>> What is their role in the big picture, i.e., in relation to the last
>>> bullet's questions?
>>
>> Noted. Some time very soon I guess I need to have another go at
>> describing the whole idea from the top down. (n.b. The terms 'sibling'
>> and 'instance' have now gone away, partly influenced by your
>> feedback.)
>>
>>> It seems, in fact, that mv-t-2 tries to solve the "Branches as
>>> a first-class concept" problem too. Perhaps this point should be
>>> highlighted better? It might attract more eyes, and phrasing it as
>>> a first-class goal could only be helpful...
>>
>> Good point.
>
> 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.

>>> Conversely, you might consider forgetting about complex branching
>>> schemes (e.g., nested branching and subtree branches; basically, stuff
>>> as uncommon in "in the wild" branching patterns as op-depth is in "in
>>> the wild" working copy patterns) and for now focus on getting move
>>> tracking right in the context of one or two or three specific
>>> branching patterns that are commonly used โ€” i.e., divide and conquer.
>>
>> That line of thought didn't work out quite the way I imagine you're
>> imagining it.
>>
>> The simplest form of branching is what basically all the DVCS's use:
>> you can branch the whole path-space of the repository, and the
>> branching is an additional dimension. You can think of it as parallel
>> histories of commits, and indeed it's often implemented that way.
>>
>> Branching into the same name-space (path-space) as the stuff you're
>> branching, as done in Subversion, requires a solution that
>> distinguishes the "branching" from the "stuff". Once that basic
>> concept is in place, then subtree branching, nested branching, and so
>> on seem to come out (more or less) as emergent properties of the
>> necessary model rather than additional features that would need to be
>> squeezed in to it.
>
> 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.

> 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.)

- Julian
Received on 2015-04-27 22:02:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.