Quoting Bill Tutt <rassilon@lyra.org>:
>
>
> > From: Branko Cibej [mailto:brane@xbc.nu]
> >
> >
> > Very necessary, imho. We have files and directores today, and can
> > predict (internal) references and (external) symlinks.
> >
> > Predecessor and copy history should be merged, and generalized. Any
> node
> > can have any number of ancestors and descendants. The fact that
> we're
> > storing copy history separately right now is an artifact of the
> current
> > node id scheme, which encodes single-predecessor revision history.
> > (Which is nuts, but we're all aware of that now. :-) Node history is
> a
> > DAG, too, and should be represented as such.
> >
>
> Actually, copy history is very important to be kept separately because
> that's the only concept SVN has of "branch" tracking atm.
>
> If we don't maintain copy history in a distinctly different fashion,
> we
> won't be able to integrate that information in when we finally support
> some kind of "Branch management schema"
I don't agree. Branches are not a "timeless concept of the filesystem".
What's more, we have no way of knowing whether a copy has "branching" or
"history" semantics. And anyway, there's no semantic difference between
the two; a branch is just a fork in the node's timeline, and there's no
reason to suppose -- *at the filesystem level* -- that one arm of the fork
is more "important" than another. What we /should/ record at that level
are both forks and merges of nodes. (We have no way to express a node merge
at the moment, only a merge of nodes' contents.)
We should stop thinking of directory copies as branches, because they're
not. That's really just a crutch for people who are used to having
branches. IMHO, any sort of branch management should not be expressed in
the filesystem structure. We have other, much more suitable mechanisms for
that -- namely, revision properties.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 12:03:02 2002