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

Re: what is Ben working on?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-02-07 17:17:14 CET

Branko Čibej <brane@xbc.nu> writes:

> Ben Collins-Sussman wrote:
>
> >I'm still working on getting 'svn switch' to work on a single file.
> >We all agree on how to do it: just do an RA->get_file on the thing;
> >don't try to use any editors.
> >
> I'm becoming a bit confused about this. Switch single file uses
> ra->get_file ... for a dir, use editors ... now what about 'svn switch
> <url> foo bar', where both foo and bar are files? cal ra->get_file
> twice? What about three files?

[sussman@kepler:~]$ svn help switch
switch (sw): Update working copy to mirror a new URL
usage: switch [TARGET] REPOS_URL

   Note: this is the way to move a working copy to a new branch.

Valid options:
  -r [--revision] arg: specify revision number ARG (or X:Y range)

It might not be clear from that help doc, but 'switch' takes *exactly*
two arguments: a single wc path, and a single URL. Right now, that
URL is required to be in the same repository as the wc path, and it
also required to be the same node type.

So -- if we're switching a wc dir to a new URL dir, it's just a
typical update driven by dir_delta. (dir_delta generates tree-deltas,
and thus only knows how to compare directories.) The only difference
is that dir_delta is comparing two *different* fs-paths; for normal
updates, the fs-paths are identical, but in different revision trees.

If we're switching a wc file to a new URL file, then we just suck down
the whole file and "install" it into the working copy, using shared
code from the update-editor's close_file().

Making sense?

---------------------------------------------------------------------
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:37:05 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.