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

RE: RE: Re: fs dump/restore proposal

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-04-24 16:40:14 CEST

> 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.
> > 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
> > a
> > > DAG, too, and should be represented as such.
> > >
> >
> > Actually, copy history is very important to be kept separately
> > 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
> > some kind of "Branch management schema"
> I don't agree. Branches are not a "timeless concept of the
> What's more, we have no way of knowing whether a copy has "branching"
> "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
'What are the set of files that might be merge source candidates for

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
> reason to suppose -- *at the filesystem level* -- that one arm of the
> is more "important" than another. What we /should/ record at that
> 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
> 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
> the filesystem structure. We have other, much more suitable mechanisms
> 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.


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

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.