SVN import

davesnb
davesnb used Ask the Experts™
on
Hello EE,

I am new Apache SVN , I have recently installed apache SVN using https://www.itzgeek.com/how-tos/linux/centos-how-tos/install-apache-svn-subversion-on-centos-7-rhel-7.html . I have created a new repository called "subversion " and wish to import a copy of an existing repository on another centos server into this new  svn instance . Can you please provide the proper direction on this matter .

CentOS Linux 7 (Core) , Apache /2.4.6 ( Red Hat Enterprise Linux)
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
Are you looking to just bring over a current snapshot of the files from the existing repository? Or are you trying to bring over the entire repo along with its history?

If it's the entire repo, then you just need to copy the existing repository's files over - you don't even need to create a new repository. Just literally copy all the server's repository files over to the new server and you should be able to access the repo (with an SVN client) from the new server. It should preserve all the history, branches, etc...

If it's just the current snapshot, then what you want to do is perform an EXPORT of the existing repository. This is just like checking out the repo except you won't have those .svn folders - it's just the raw content from a specific revision. From there, you can simply checkout the new repo, and then add and commit the exported files.
Commented:
On a side note, if you're considering moving to a fresh, new repository, you might want to consider using Git for version control. I used to use SVN all the time, but it has some big weaknesses:

1. It slows down a lot over time so that even small checkouts and commits can take a long time.
2. Branching is very inefficient (it's basically like having a full copy of your repo for each branch).
3. It's very susceptible to failure (if your server repo gets corrupted, then there's usually no way to recover)

It does have a few advantages like incrementing numeric revisions (revision 1, revision 2, etc) and some nice GUIs like Tortoise, but that's about it.

Git is what everyone is moving to these days because it's VERY fast and very efficient across the board, and it is VERY resilient to failure. Anyone who "checks out" the repository will have a full copy of the repository that can be used to easily recover from failures.

Also, when you are working on the files, you only have one .git subfolder in your working copy, instead of having .svn folders in every single subfolder, which makes your working copy a lot cleaner and easier to manage.

To put it into perspective, one of my enterprise projects used SVN from 2004 to 2012. Near the end, the repository was several gigabytes and took FOREVER to check out. We had two different failures over the course of those years and it took a long time to recover. Near the end, every commit and checkout could take upwards of 15-30 seconds.

We switched over to Git and I imported all the revisions into Git so we kept all the commit history, and the repository was a little less than 100 MB. The average commit for that repository in Git takes less than 5 seconds, and it stays that way (and since the repo is so much smaller, the checkouts/pulls are much faster too). Branches are done in a very efficient way so they don't really take up any space beyond the actual commits.

There's a little bit of a learning curve, but it's well worth it. There are Git clients for every operating system. While most people just use the command line, there is a "Git GUI" option, and if you need a nicer-looking, more polished GUI, there is one called SourceTree.

Again, just something to consider.

Author

Commented:
Thanks !

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial