How to mirror a SVK repository onto an SVN repository
Posted by Scott Laird Fri, 15 Jul 2005 07:55:38 GMT
As mentioned before, I’ve been using SVK to manage the changes that I’ve been making to Typo.
One of the items on my SVK to-do list was to figure out how to mirror a local SVK repository onto a public Subversion server. This is useful for a number of reasons:
- It provides a backup if the local SVK tree is lost.
- It allows me to use SVK on my laptop and work against the same SVK tree that I’m managing on my server.
- It allows others to see what I have in my SVK tree.
The SVK documentation doesn’t provide an exact recipe for doing this, but it turns out to be pretty simple. First, make sure that you have a publicly-accessible Subversion server where you have write privileges. Follow the Subversion Book if you need help with this.
Next, tell SVK to mirror a chunk of the Subversion share into your local SVK depot:
$ svk mkdir //mirror
$ svk ls http://svn.scottstuff.net/public/
<follow the prompts and have it mirror it onto //mirror/public>
$ svk sync --all
$ svk mkdir //mirror/public/typo
$ svk smerge --baseless //typo/ //mirror/public/typo -m 'Initial publication'The final mkdir operation should prompt you for your Subversion username and password; once this is done, you should have write access to the Subversion share for all future operations.
One thing that I probably should have done was use the -Il option to smerge instead of -m. With -Il, SVK commits each local change to the remote server individually, using the local commit message. Without it, all changes get bundled up in one big change, and this isn’t really ideal.
At this point the public Subversion server should have a complete copy of your local Typo tree. To keep it up to date, you’ll need to run something like svk smerge -Il //typo/ //mirror/public/typo from time to time.
Hey Scott, just wanted to say thanks for posting this info. Just put this into play for my new typo setup (after wondering just how I’d version stuff in the tree) and it works great!
Though I think I might pull staging from my setup, since I mirror production into the live web root…..
This deserves more pagerank, and/or to be written up in a HOWTO somewhere. I successfully used this to manage a fork of my employer’s LGPL libraries to do some highly experimental local work on scalability and clustering over the past three months, and it’s worked amazingly well.
Hi Scott,
I like this setup in place of a traditional vendor branch, but it seems like this solution really only works for a team of 1 since all changes must be checked into your local svk. I guess other team members could commit to the public svn repository, but then how would you get those changes back upstream?
It seems the best solution for a team would be to have the typo svk branch double as a publicly accessible svn repository. So instead of just mirroring the svk depot, would there be a way to depotmap your svk depot to a public svn repository? Do you see something like this working?
I was hoping to get some direction from someone familiar with SVK before trying to do this. Perhaps you have an even better solution than what I am thinking?
Peter
Hi Scott,
I like this setup in place of a traditional vendor branch, but it seems like this solution really only works for a team of 1 since all changes must be checked into your local svk. I guess other team members could commit to the public svn repository, but then how would you get those changes back upstream?
It seems the best solution for a team would be to have the typo svk branch double as a publicly accessible svn repository. So instead of just mirroring the svk depot, would there be a way to depotmap your svk depot to a public svn repository? Do you see something like this working?
I was hoping to get some direction from someone familiar with SVK before trying to do this. Perhaps you have an even better solution than what I am thinking?
Peter
I was just browsing around looking into distibuted version control system.
The thing is I couldn’t really think of a probably usecase for my own work. But this and your three previous SVK articles do seem to show a nice way to deal with non-writable subversion remote repos.
Since I am still unfamiliar with distribted systems like SVK, Darcs, Git, HG, etc… I am trying to figure out more probable usecases applicable to me. Thanks for the info.
Just a question. I’ve seen your post from awhile ago. Still using SVK? Has it met your expectations? Stability issues? had any data loss?
(Would be a nice follow-up post.)