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

Re: copy-planz.txt

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-11-17 04:00:03 CET

On Thu, Nov 15, 2001 at 01:26:27PM -0600, cmpilato@collab.net wrote:
>...
> * Case II - SRC is working copy path, DST is repository URL:
>...
> If this a `move' operation, SRC (or, the URL associate with SRC in
> the repository) will be deleted as part of the commit process.
>
> The working copy is never modified during this process is this is a
> `copy'. For `move's, we *could* go ahead and remove SRC in the
> working copy, but I'm planning to just take the easy route for now
> and require the user to update. I'd like to keep this a WC-free
> operation.

I think a move to a URL should be illegal. It is hard to really define what
the logic "should" be. With a copy, it seems pretty obvious that your WC
won't be affected (you're just copying it). But a move is different. But
with a move, you've got trouble.

a) You modify the WC. This is different than the copy case. I'd also be wary
   of accidentally deleting unversioned files in the WC. Seems dangerous.

b) You don't modify the WC. That leaves a bunch of stuff in the WC that
   "shouldn't be there." Fine, it will get fixed on the next update. But
   wait: if you have local mods, then you're going to get conflicts all over
   the place on an update. Copies don't have that problem.

Moving to a URL doesn't really make good sense under either option.

> * Case III - SRC is repository URL, DST is working copy path:
>
> There are two routes to take with this:
>
> - Treat this as a Case IV (using DST's constructed repository URL)
> plug a checkout of DST, or

A copy from a URL to a working copy seems okay (but only under the semantics
of the next option). But a move doesn't. Again, it is that edge case that
you're doing two things: a commit in the repository *and* a checkout to the
WC. Eek.

> - Treat this is a special checkout of SRC (at the optionally supplied
> revision, even), except that once the checkout is complete, you
> have DST scheduled for commit as a copy.

These semantics make sense for copying from a URL to the working copy.

> I personally like the former, seems cleaner to me, and it allows
> `move's to happen atomically.

I don't think a move should happen. The behavior isn't intuitive.

> * Case IV - SRC is repository URL, DST is repository URL:
>
> This is a freaky special commit drive, where we operate purely on
> our ability to split paths up into components, and then "crawl"
> those trees based purely on the layout of those path components.
> Actually, for copies this is pretty much a four-line commit:
>
> e->replace_root (dst)
> e->add_(file/dir) (dst_basename, copyfrom=src)
> e->close_dir
> e->close_edit
>
> The part that requires all the path component attention is if this
> is a move, because we have make sure to anchor the edit at the
> longest common ancestor of SRC and DST so we can delete SRC as part
> of the same transaction as our addition of DST.

As mentioned in the other note, I don't think you even do a "crawl" or
"drive" for this, but you simply call those editor functions manually on the
editors. Very straight-forward.

This one *does* make sense for both moves and copies. I could easily see it
done for moving stuff around in a repository, and for tagging stuff.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006

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.