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

Today at 9:56am, Daniel Becroft said:

>> 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...
>
> Just out of curiosity, why not just wait until you have network access to
> the new repository before running 'svn switch'?

We're a web development shop, and whenever we start a new project, we make
a repository as part of a script we run to start up the project. The
script has to run as root, and we want it to make the repo and make the
initial commit of the skeleton files as root. The checkout we make on the
development server needs to be an svn+ssh checkout rather than a file
checkout, but if we start it out as an svn+ssh checkout, the user running
the script would need to be able to ssh into the box as root, which they
can't. So right now we're starting it as a file:/// checkout instead,
which works fine as root, and then wanted to switch it to an svn+ssh
checkout so it would be ready for users to use without needing root
access. Normally this would work just fine, because we do all the
operations we need to prior to switching it, so that it should never need
to contact the new repo as root over ssh.

However, when it tries to do the uuid check as part of the relocate, it
ends up contacting the server, which wants root's login credentials.

Hm, I may be able to make a workaround with SVN_SSH now that I think about
it... making it use ssh -l <realuser> instead of letting it attempt to ssh
as root (the effective user). Maybe I'll give that a try.

The setup we have here (for a lot of reasons I won't go into) is that many
of us use ssh to log into the various development and production servers,
and need to be able to update the working copy there as themselves
(without root access). The development servers all share filesystems over
the network, so the repository checkout needs to be svn+ssh so the
repository actions all occur on the same server. (Some of the dev server
run different OS versions and different SVN versions, but I always want
one server doing the repo accesses so that it doesn't corrupt it by having
older versions messing around with it. That and file locking doesn't work
properly over the network file shares, so a file:/// checkout doesn't
work right except on the main server.)

I was very confused at first, because I remember when --relocate didn't
need to contact the repo, since it is purely a working copy change that
doesn't need any information from the server. This is the first time I've
needed to do a switch as root rather than as myself, so I didn't know
until now that it had started needing network access.

Long answer to a short question :)

Thanks,
Mac

--
Mac Newbold			Code Greene, LLC
CTO/Chief Technical Officer	44 Exchange Place
Office:	801-582-0148		Salt Lake City, UT  84111
Cell:	801-694-6334		www.codegreene.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390699
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].