Daniel Shahaf wrote (quoting two emails combined):
> Okay. So what you're saying so far is that the data model will have
> distinct concepts for "copying" and "branching".
Yup.
> Presumably [...] 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.
Usually, in practice, many elements are branched together, and this is
reflected in the model. Unlike copying, a branch contains a *set* of
elements. New elements can be added to the set later: this happens,
for example, when we merge the changes into this branch from a source
branch in which new elements have been created. Elements removed from
the branch can be re-added later as the same element ("resurrection").
This is a significant difference from the old model of 'copying' where
each element (each file and directory) gets an independent new id [1].
And it matters particularly when you have the ability to move elements
around in the tree -- you need a way to track which elements are
members of which branch.
[1] In the existing Subversion back-end, on copying a directory, each
file and directory in it gets a new copy-id once lazy copying is
undone. (For modelling purposes, lazy-copying hardly matters. As a
thought experiment, imagine on top of the old Subversion back-end we
build a version control system that, as part of its design, always
makes a small modification to each file and directory when copying.
Thus we never see 'lazy copying' and always see a new id for each
file/dir.) These new ids are independent for each file/dir: there is
no way to group them into sets.
Another significant property of a branch in this model is the
one-to-one correspondence between the (instances of) elements in this
branch and those in another branch, for the elements that appear in
both of the branches.
> 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?
[...]
A 'branch' is an atomic (not derived) concept of the model. And, as
said above, a branch is not a node, it's a container containing
instances of a set of elements.
> By the way, if the data model has a first-class 'branch' operation, will
> it also have a first-class 'tag' operation?
It will be possible to use a 'branch' as a 'tag' in the same limited
sense as in the old model. I have not looked at introducing a
different kind of tagging.
> And where would the
> distinction between 'feature branches', 'stabilization branches', etc.,
> live?
That would live in a higher layer. The model I'm presenting attempts
only to provide sufficient foundation for move tracking in merging.
The branches in the model have no classes of relationship between
them: they are all the same. I envisage that kind of functionality
being built in a layer on top of this model.
> That is: would the hypothetical "SCM-knowledgeable user not familiar
> with SVN" want to tell her SCM the merges pattern of each branch (which
> branches it may merge from/to), and have the SCM enforce that?
>
> Daniel
> (An "SCM-knowledgeable user not familiar with SVN" is the end-user with
> whom in mind the data model is designed)
Yup.
Thanks again for your thoughtful questions. How much is making sense?
- Julian
