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

Re: [PATCH] Allow copy files that already copied

From: Jim Blandy <jimb_at_red-bean.com>
Date: 2005-12-03 01:47:30 CET

On 02 Dec 2005 17:10:52 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> > I propose to allow this and make foo3 take foo's URL as copyfrom-url.
> Hmmm. But why is that correct? foo3's copyfrom-url is not foo's URL,
> it's foo2's (but foo2 doesn't have a URL yet, really, so that's not
> quite right either).
> > Look to attached patch.
> > Yes, I know it is bit confusing, but it is usefull, especially for
> > refactoring.
> I understand that this might make certain operations easier, but I
> think we need solid theoretical grounding for any such change. Being
> convenient (in some circumstances) is not the same as being correct.

The same thing came up in the conversation about Garrett's new replay
function. Greg Hudson said that Subversion deltas weren't composable.

 r1: add foo (no history)
 r2: delete foo
 r3: add foo (copy history foo@1)
 r4: add bar (copy history foo@1)

Greg challenged me to describe the composition of r1 -- r4. I said:

  If 'copy with history' could refer to a file added in the same delta,
  the composition would be:
  - add foo (no history)
  - add bar (copied from our new foo)

Notice that the answer here also involves history referring to things
in the current transaction. Now Ivan has pointed out that these
histories actually occur in normal working copies, too. So even
uncomposed deltas already have such things going on, or would, if we
didn't forbid it.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 3 01:50:51 2005

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.