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

Re: svn switch --relocate needs access the repo(s)?

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Thu, 3 Sep 2009 09:56:13 +1000

On Thu, Sep 3, 2009 at 8:12 AM, Mac Newbold <mac_at_codegreene.com> wrote:

> In older versions of subversion, it seems that the --relocate switch would
> let you change the URL to your repository without needing to contact the
> old repository nor the new one. It would simply make the changes to the
> local working copy.
>
> In current documentation here:
> http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.switch.html
>
> It looks like that has changed, and now it insists on accessing the URL
> before it will carry out the changes to the working copy.
>
> Is there any way to get the old behavior again? I tried the --force
> switch, but it still fails if it can't contact the new repo.
>
> My situation is this: I need to run a switch --relocate under conditions
> where I can't connect to the new repo, but still need to make the changes
> to the working copy so that I can access the repo properly later.
>
> Any ideas?
>
> I'm all in favor of sanity checking, as long as there's a way to override
> it with a flag for "i know what I'm doing", which I thought is what
> --force was intended to be. Maybe a "don't access the network" flag would
> be even better.
>
> If svn itself refuses to do it, I guess I'm back to using perl or sed to
> do the replacement in the .svn/entries files...
>
> Thanks,
> Mac
>

Just out of curiosity, why not just wait until you have network access to
the new repository before running 'svn switch'?

Cheers,
Daniel B.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390475

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-03 01:57:30 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.