You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mac Newbold <ma...@codegreene.com> on 2009/09/02 22:12:45 UTC
svn switch --relocate needs access the repo(s)?
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
--
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=2390451
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: svn switch --relocate needs access the repo(s)?
Posted by Mac Newbold <ma...@codegreene.com>.
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@subversion.tigris.org].
Re: svn switch --relocate needs access the repo(s)?
Posted by Daniel Becroft <dj...@gmail.com>.
On Thu, Sep 3, 2009 at 8:12 AM, Mac Newbold <ma...@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@subversion.tigris.org].
Re: svn switch --relocate needs access the repo(s)?
Posted by Mac Newbold <ma...@codegreene.com>.
Tomorrow at 12:10am, Stefan Sperling said:
>> 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.
>
>> 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.
>
> Yes, we could provide a command-line switch that disables this check,
> like --i-know-what-i-am-doing or maybe even --no-uuid-check.
>
> Would you take the time to file an issue to track this enhancement
> request? It should not be hard to do this and maybe someone will find
> the time to implement this before 1.7.0 is released.
Done:
http://subversion.tigris.org/issues/show_bug.cgi?id=3476
> In return for filing the issue, and if you really need this enhancement
> right now, you could try disabling the uuid check with the patch below
> (against 1.6.x). I haven't tested this patch but I think it should do
> the trick.
Thanks!
Mac
> Stefan
>
>
> Index: subversion/libsvn_client/relocate.c
> ===================================================================
> --- subversion/libsvn_client/relocate.c (revision 39053)
> +++ subversion/libsvn_client/relocate.c (working copy)
> @@ -58,6 +58,7 @@
> const char *root_url,
> apr_pool_t *pool)
> {
> +#if 0
> struct validator_baton_t *b = baton;
> struct url_uuid_t *url_uuid = NULL;
>
> @@ -104,6 +105,7 @@
> (SVN_ERR_CLIENT_INVALID_RELOCATION, NULL,
> _("The repository at '%s' has uuid '%s', but the WC has '%s'"),
> url, url_uuid->uuid, uuid);
> +#endif
>
> return SVN_NO_ERROR;
> }
>
--
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=2390468
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: svn switch --relocate needs access the repo(s)?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 02, 2009 at 04:12:45PM -0600, Mac Newbold 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.
The client contacts the server to find the UUID of the repository
you are switching to. It will complain if the repository UUID recorded
in the working copy and the one retreived from the repository you
are relocating to don't match. That explains your problem.
> 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.
> 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.
Yes, we could provide a command-line switch that disables this check,
like --i-know-what-i-am-doing or maybe even --no-uuid-check.
Would you take the time to file an issue to track this enhancement
request? It should not be hard to do this and maybe someone will find
the time to implement this before 1.7.0 is released.
In return for filing the issue, and if you really need this enhancement
right now, you could try disabling the uuid check with the patch below
(against 1.6.x). I haven't tested this patch but I think it should do
the trick.
Stefan
Index: subversion/libsvn_client/relocate.c
===================================================================
--- subversion/libsvn_client/relocate.c (revision 39053)
+++ subversion/libsvn_client/relocate.c (working copy)
@@ -58,6 +58,7 @@
const char *root_url,
apr_pool_t *pool)
{
+#if 0
struct validator_baton_t *b = baton;
struct url_uuid_t *url_uuid = NULL;
@@ -104,6 +105,7 @@
(SVN_ERR_CLIENT_INVALID_RELOCATION, NULL,
_("The repository at '%s' has uuid '%s', but the WC has '%s'"),
url, url_uuid->uuid, uuid);
+#endif
return SVN_NO_ERROR;
}
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390462
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].