> From: brane@xbc.nu [mailto:brane@xbc.nu]
>
> 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.
A copy with "history" semantics is a read-only "branch". I.e. I don't
care if they never modify the sucker, I just want each of the copies
tracked so that branches can be developed later.
If we don't encode the copy information there's no way later that you
could create appropriate schema to help manage branches and migrate the
existing data into this new "branch management schema". A fundamental
query in a SCC system that SVN just fundamentally doesn't support atm
is:
'What are the set of files that might be merge source candidates for
myself?'
Not being able to easily answer this question is an annoying blow to
being able to construct a usable UI to help out the merge process.
> 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.)
>
Hopefully we can fix that problem when Ben Sussman makes the ID change
for the NodeRevision table. That's very obnoxious. Additionally, copies
aren't just part of the ancestor history. (Although they are). They're
stored separately for useful reasons. i.e. To know the source path of
the copy, and the repository version the copy was made.
> 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.
>
Whatever our future branch management schema is, obliterating the copy
data will prevent you from inferring what the set of branches should be.
Besides, revision properties aren't nearly enough to specify branch
behavior, or indeed being able to query them efficiently.
I suppose I should just find the time and think about what real branch
management schema should look like.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 16:41:31 2002