RE: Re: fs dump/restore proposal

I agree, I don't think we can toss the distinction either.

Bill

----
Do you want a dangerous fugitive staying in your flat?
No.
Well, don't upset him and he'll be a nice fugitive staying in your flat.
 
> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Wednesday, April 24, 2002 8:27 AM
> To: Bill Tutt
> Cc: brane@xbc.nu; SVN Dev List
> Subject: Re: fs dump/restore proposal
> 
> "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.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org