You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michael Xenakis <xe...@serv.net> on 2009/01/04 19:02:45 UTC

Accessing single repo w/ multiple host names

Happy New Year all!

I was hoping someone could provide some insight on SVN administration and an issue I'm having.  I've recently (yesterday) setup a repository to help me organize my school projects and class work.  My home network is pretty lightweight - which is to say I have no internal DNS.  Therefore, when importing and doing my initial checkout, I referenced the server using it's internal name - to be more specific:
svn+ssh://minitron.local/...

I did that as it's quicker than having all the traffic exit the network and return.  Now, however, I'm trying to test that I'll be able to access the server externally as well, i.e., svn+ssh://external.domain.name/...

When running a status on my checked repository, I'm told that it's not a working copy:
svn: warning: 'svn+ssh://external.domain.name/Volumes/dumpster_diver/svn_root' is not a working copy

My thought is this is the result of the .svn/entries file listing minitron.local as the SVN server while I'm trying to now point to external.domain.name.  Given, however, that I know they're the same repository, is there a way to (easily / quickly) get SVN to treat the server names the same?

As I'll be accessing the repo both from home and school, it would be nice to have the option of using the internal network for speed when at home.

Thanks,
mX.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Accessing single repo w/ multiple host names

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 4, 2009, at 13:02, Michael Xenakis wrote:

> I was hoping someone could provide some insight on SVN  
> administration and an issue I'm having.  I've recently (yesterday)  
> setup a repository to help me organize my school projects and class  
> work.  My home network is pretty lightweight - which is to say I  
> have no internal DNS.  Therefore, when importing and doing my  
> initial checkout, I referenced the server using it's internal name  
> - to be more specific:
> svn+ssh://minitron.local/...
>
> I did that as it's quicker than having all the traffic exit the  
> network and return.  Now, however, I'm trying to test that I'll be  
> able to access the server externally as well, i.e., svn+ssh:// 
> external.domain.name/...
>
> When running a status on my checked repository, I'm told that it's  
> not a working copy:
> svn: warning: 'svn+ssh://external.domain.name/Volumes/ 
> dumpster_diver/svn_root' is not a working copy

"svn status" operates only on working copies. It does not operate on  
repository URLs.

If you're just trying to verify that the repository is accessible  
under the external domain name, perhaps you want:

svn info svn+ssh://external.domain.name/Volumes/dumpster_diver/svn_root


> My thought is this is the result of the .svn/entries file listing  
> minitron.local as the SVN server while I'm trying to now point to  
> external.domain.name.  Given, however, that I know they're the same  
> repository, is there a way to (easily / quickly) get SVN to treat  
> the server names the same?
>
> As I'll be accessing the repo both from home and school, it would  
> be nice to have the option of using the internal network for speed  
> when at home.

There should be no problem making a repository available under  
multiple URLs. You can check out a working copy at home using one URL  
and from school using the other. If you ever need to move a home  
working copy to school, you can fix the working copy using

svn switch --relocate <INT_URL> <EXT_URL>

or vice versa.

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].