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

Re: fs dump/restore proposal

From: <brane_at_xbc.nu>
Date: 2002-04-24 18:07:31 CEST

Quoting Ben Collins-Sussman <sussman@collab.net>:

> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > 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.
>
> Bill and Branko,
>
> Hold on a sec, guys. Here's my fundamental problem with combining
> predecessor-history with copy-history: they're different things.
> There's definitely a difference between *changing* a file and
> *copying* a file. In one case, you create a successor, in another
> case, you have a copy with history. These are distinct events, and I
> don't see why we should toss this distinction.

I'm saying that, as we use copies now, there *is* no distinction.
The only discernible difference in the current implementation is
that, when you modify a file, its successor is a new version of
the same node; when you copy it, it's a new node. But that's an
implementation detail. We do it that way because that makes it
easier for us at the *next* change made to the copy, or the
directory it contains.

Forget about svn commands for a moment and imagine a node's history:

     1 -- 2 +- 3 -- 5 -- 7 -+ 8 -- 9
             \ /
              +- 4 -- 6 -+

It forks and it joins, but it's still the same node. Branching
should only affect a single node's history, not create new nodes.
That's what copying is for.

Hm. Now I find myself agreeing with you. :-) Yes, there's a
difference between creating a successor and creating a copy.
But we can't tell the difference today, because "svn copy"
always creates copies, even when we really want a successor
(i.e., a branch). So, even if we separate the two concepts in
the dump format, what we see there will be wrong. ...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 18:08:59 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.