Rename Repository

[bob2oneil]

I am using uberSVN at both home and office under Windows, and these machines have different network names, and therefore the same Tortoise checkout does not match between machines.
To ease the notion of using the same client checkout with two different repositories, I renamed the home machine to match that of the office machine.

Unfortunately, when the repository was created, it contains the machine network name as part of the URL as the location (as opposed to what could be a varying IP address).

Is it possible to rename an existing repository?

If not, what is the easiest procedure for recreating one with maching repository names (e.g. export from one server, then do an import on the other).

[ljolly]

Hi Bob,

I'm afraid I don't follow what you're trying to do. Am I right in thinking you have two separate repositories but you want to be able to commit from your working copy to either?

Thanks,
Liam

[mbooth]

If you are just trying to copy the contents of one repository into another repository, there are the svn export and svn import commands or the svnadmin dump and svnadmin load commands, depending on how deep a copy you want.

A working copy will only point to one repository, however. There is svn switch --relocate but that's really only for when your repository has moved to a new location. Why is it you think you need your working copy to point to two different repositories?

[bob2oneil]

Hi Bob,

I'm afraid I don't follow what you're trying to do. Am I right in thinking you have two separate repositories but you want to be able to commit from your working copy to either?

Thanks,
Liam

Thanks for your input, you are correct, I have two repositories on different servers (geographically separate) that I would like to commit two using a common laptop. While I could certainly use
different folders on the laptop (since Tortoise embeds the repository name as part of the checkout), to harmonize between the two repositories, I was going to use the same network name
for both. I am using network names rather than IPs because the IPs are different between locals, and change via DHCP as well.

[bob2oneil]

Hi Matt, the export/import method might be sufficient, it is a young repository, so I don't really need to have the historical change history. I was just wondering if there was a simple rename operation available, where my repository,
which was at "http://machineName1:9880/repository" could be renamed to "http://machineName2:9880/repository". In that manner, I was expecting that client checkins from the laptop that gets carried to each site would refer
by name to the same repository. The two repositories would not necessarily have the same checkin frequencies, one might be more frequent than the other. There may be better options to handle this workflow, open to ideas.

[andyl]

Thanks for your input, you are correct, I have two repositories on different servers (geographically separate) that I would like to commit two using a common laptop. While I could certainly use
different folders on the laptop (since Tortoise embeds the repository name as part of the checkout), to harmonize between the two repositories, I was going to use the same network name
for both. I am using network names rather than IPs because the IPs are different between locals, and change via DHCP as well.

Sorry, this just won't work, and Subversion is not designed such that it can work. A working copy can only be linked to a single repository, and trying to "trick" it by using the same hostname won't work because the WC knows what revision it should be expecting on the server. What you're proposing would result in the WC being at a later revision number than the "second" repository, and that will prevent a commit from happening.

If you want to keep 2 repositories in sync, you should be using svnsync (see also http://svnbook.red-bean.com/en/1.7/s...nt.replication), and always commit to the same repository (unless you're using a write-through proxy too. WANDisco also has products you can purchase to achieve this.

[bob2oneil]

That makes sense, I guess my solution of using two separate folders between repos, and handling the harmonization between them myself will be required.

[andyl]

That makes sense, I guess my solution of using two separate folders between repos, and handling the harmonization between them myself will be required.

Until you slip somewhere and get burned.

Subversion already has the tools to do this safely, take advantage of them.

[bob2oneil]

Until you slip somewhere and get burned.

Subversion already has the tools to do this safely, take advantage of them.

Good points, I am not familiar with svnsynch. Will this work when the repositories are not availabe on the same network. One repository is on a home network, the other on a company network that is not exposed for external access.

Perhaps if the office repo was exposed, there would be no need to have the home repo, but we currently want the office repo to not be exposed while we work out security issues.

[mbooth]

Good points, I am not familiar with svnsynch. Will this work when the repositories are not availabe on the same network. One repository is on a home network, the other on a company network that is not exposed for external access.

Perhaps if the office repo was exposed, there would be no need to have the home repo, but we currently want the office repo to not be exposed while we work out security issues.

The office repo doesn't have to be exposed to the Internet, we have VPNs for a reason

[andyl]

Good points, I am not familiar with svnsynch. Will this work when the repositories are not availabe on the same network. One repository is on a home network, the other on a company network that is not exposed for external access.

Perhaps if the office repo was exposed, there would be no need to have the home repo, but we currently want the office repo to not be exposed while we work out security issues.

mbooth is correct, you should be using a VPN there, and sync when you re-establish the connection. But beware that you can't really do a bi-directional sync with svnsync - it's designed to go in one direction (hence the write-through proxying), so if you commit to both repositories, you'll end up in a real bind. IIRC, one of WANDisco's products does have the ability to handle this sort of a setup, but it'll cost money.

However, I have to say that your setup is a bit unorthodox. Most companies wouldn't (knowingly) allow you to maintain a "home" repository that mirror's the company's, and vice versa. Company materials stay off personal devices, and personal data stays off corporate computing resources. Even if it's your own company, I'd expect that you'd separate the company stuff from your personal stuff just a matter of protecting your personal assets against bankruptcy, lawsuits, etc.

[bob2oneil]

The office repo doesn't have to be exposed to the Internet, we have VPNs for a reason

Good point, we just setup a small office and have not setup VPN access. Perhaps we need to accellerate that effort.

[bob2oneil]

mbooth is correct, you should be using a VPN there, and sync when you re-establish the connection. But beware that you can't really do a bi-directional sync with svnsync - it's designed to go in one direction (hence the write-through proxying), so if you commit to both repositories, you'll end up in a real bind. IIRC, one of WANDisco's products does have the ability to handle this sort of a setup, but it'll cost money.

However, I have to say that your setup is a bit unorthodox. Most companies wouldn't (knowingly) allow you to maintain a "home" repository that mirror's the company's, and vice versa. Company materials stay off personal devices, and personal data stays off corporate computing resources. Even if it's your own company, I'd expect that you'd separate the company stuff from your personal stuff just a matter of protecting your personal assets against bankruptcy, lawsuits, etc.

I and a couple of other guys are the company, we maintain the separate repos in part for offsite storage and as a workflow until we establish our networking infrastructure and security.
It is clearly an interrum solution, and one for which you guys have correctly pointed out is problematic in many ways. The home repo is essentially a tool that allows for more
frequent daily checkins when we are working from home, which is often, with the notion that daily checkins would be provided as weekly checkins to the corporate repo.

Thanks for everyones comments and suggestions.

[mbooth]

Also: Source control systems are not back up systems and Subversion should not be used as such. You would be wise to set up a separate back up process.

[andyl]

The home repo is essentially a tool that allows for more
frequent daily checkins when we are working from home, which is often, with the notion that daily checkins would be provided as weekly checkins to the corporate repos

Have you considered using a VCS better-suited to this type of setup, like Mercurial or Git?

But that still doesn't address the separation of personal vs. company.

[bob2oneil]

Have you considered using a VCS better-suited to this type of setup, like Mercurial or Git?

But that still doesn't address the separation of personal vs. company.

The decision on SVN vs. GIT was not rigorously researched, SVN was probably the more familiar. Perhaps I need to research the benefits of GIT vs. SVN.

I appreciate all the input, the daily/weekly checkin to the two repositories does seem to work in practice, although the revision counts do not seem to jump contiguously,
where the weekly repository jumps from say revision 1 to revision 5 for a single checkin, for which there is probably an explanation.

I recognize that during the weekly office checking, many individual changes are bundled into a less granular checking.

I consider this an interrum working solution until such a time that we establish VPN and utilize a singular repository.

[andyl]

The decision on SVN vs. GIT was not rigorously researched, SVN was probably the more familiar. Perhaps I need to research the benefits of GIT vs. SVN.

I appreciate all the input, the daily/weekly checkin to the two repositories does seem to work in practice, although the revision counts do not seem to jump contiguously,
where the weekly repository jumps from say revision 1 to revision 5 for a single checkin, for which there is probably an explanation.

I recognize that during the weekly office checking, many individual changes are bundled into a less granular checking.

I consider this an interrum working solution until such a time that we establish VPN and utilize a singular repository.

The way you're working right now, I would really recommend you take a closer look at Mercurial, Git, or another DVCS. SVN may have been picked because that's what you know, but the way you're operating right now is much, much better suited to a DVCS.

[andyl]

Also: Source control systems are not back up systems and Subversion should not be used as such. You would be wise to set up a separate back up process.

Nah, as long as you've got the repository on a RAID5 volume, you don't need a separate backup. Right, guys?

Guys?

Anyone?

[ljolly]

Just out of curiousity bob2oneil how many users currently use those repositories?