UsingSVKAsARepositoryMirroringSystemZh -- Chinese Version
e-Hernick: SVK is an elaborate perl wrapper that adds functionality to SVN. With SVK, you can build a distributed versioning system on top of SVN.
e-Hernick: clkao, creator of SVK, are you saying that SVK now features good performance ?
clkao: SVK happens to be 2 to 3 times faster for me, most of the time. It has featured performance for a long time.
e-Hernick: Then I will try using SVK. It's a lovely concept.
clkao: You can wait till tomororw :)
e-Hernick: What's special about tomorrow ? The big point-oh release ?
clkao: Right.
e-Hernick: I have a need for partial decentralisation. I have a 2.5GB repository, on a fast server on the Internet. But the connection here isn't that great, and three people here use that repository. Same thing for other users of this repository. They ci and up to that repository to which they've got a shitty connection. But in the interest of easier management, I don't want to end up with 50 versions of the repository. But 2 or 3 would be a great improvment for a couple of people. You can have multiple people working on the same svk mirror repository, right ?
clkao Sure. At $work we do that, because it's 1.3G repository with ~35k revs.
e-Hernick: Then svk is the solution. I'm sold. I will implement svk this week. On one project to begin with. Then I'll see. It's not a code project, it's a media repository. Used by about a dozen people in four locations. Lots of images, lots of media content. I really don't know how we'd have managed that without SVN. But the performance is an issue... When all those people have to update a few hundreds MBs. I'll need to set up and automate SVK as to make it transparent to the users, though. Most of the repository users are not programmers, and they don't know about version control. They use TortoiseSVN, and they've only been taught about very basic operations. Do you think it will be a problem ?
clkao: The only thing to note is not to commit directly to the mirrored path. Commit to local branch, and use svk push/pull.
e-Hernick: Let's take one location. 4 users. They'll all update and commit from the local branch, and nothing will change for them. However, I will have scripts to periodically sync that local branch to the central repository. The same principle will apply at most locations. However, some users will still work directly on the central repository. To avoid adding un-necessary latency, I could trigger the repository sync as a commit hook. So, at first, I'd be using svk as a single repository replicator. Once this simple setup works, I will explore the other possibilities of svk, including moving the programmers to use svk directly. Can this be done ? drugs
clkao: Sure.
e-Hernick: Then so be it. I will eagerly await the release of SVK 1.0.
is this useful? SyncReposBetweenServers b6s
/How do you do this? (Can something about this be added to the tutorial page?) My guess is below. --BrettNeumeier/
# set up the local mirror # the nameless depot lives at mirror.site:/shared/repos/dir mirror$ svk mirror svn+ssh://master.repository.site/path/to/repos/ProjectName //mirror/ProjectName mirror$ svk sync //mirror/ProjectName mirror$ svk cp //mirror/ProjectName //ProjectName # now use the local branch (//ProjectName)) as a SVN repository client$ svn co svn+ssh://mirror.site/shared/repos/dir/ProjectName/trunk ProjectName # to pull new changes from the main repository so they're available to clients of mirror.site: mirror$ svk sync //mirror/ProjectName mirror$ svk smerge //mirror/ProjectName //ProjectName # to commit changes from mirror.site to the main repository: mirror$ svk sync //mirror/ProjectName mirror$ svk smerge -C //ProjectName //mirror/ProjectName (resolve conflicts if any) mirror$ svk smerge //ProjectName //mirror/ProjectName
Is that right? Is it the best way of doing things? I was tempted to use "svk push" and "svk pull" but I'm afraid I don't really understand how they are different from "svk smerge".
Mirroring a repository on your local machine
If you're running SVK on your local machine the equivalent of the above would be the following.
# set up the local mirror svk mirror !http://repos/somewhere svk cp //mirror/repos //local/repos # now use the local branch as an SVN repository svn co -p file:///home/user/.svk/local/repos repos # pull new changes from the main repository svk sync //mirror/repos svk smerge //mirror/repos //local/repos #(update working copy) # to commit changes from mirror to the main repository: # make changes to working copy and commit with SVN or TortoiseSVN (http://tortoisesvn.tigris.org) svk sync //mirror/repos svk smerge -C //local/repos //mirror/repos #(resolve conflicts if any) svk smerge -l //local/repos //mirror/repos
I've used the //local/repos convention because I think it makes it clearer what is local and what is mirrored, but remember it's only directories, you could just as easily call it //ProjectName or even //mirror/repos-local, the important point for svn users is that it isn't interacting with any directories that have been mirrored.
-- SamHasler
This is a ThreadMode page, and I find it a bit difficult to parse. Sorry for adding noise to it. There is a mention of a tutorial, but no link. I wish this would be fine-grained and versioned, possibly with support for different opinions, if the conflicts are unresolved yet (which typically doesn't show up in a thread). The precise information I was looking for, and did not find, is: what is the mechanism use to trigger the sync from the remote repository being mirrored locally? I am still in an evaluation phase, looking at different options. I didn't install svk yet, nor tried to test-mirror an svn repository. Would I have to register something there? Or would this be polling the repos? Thanks!
-- Marc Girod [being a newcomer here, I sign wishing this would be redundant with info in the history]
A couple of backup strategies
The following seems to work for me. I start from the inverse problem, being in a unique-programmer situation: I have a local repository to which I commit, and I'd like to have separate backup repositories, in different places.
One is on a remote server to which I can access via ssh. For this, my setup is the following:
shell$ svk mirror svn+ssh://remote.example.com/path/to/svn/repository //remote shell$ svk sync //remote # does nearly nothing shell$ svk cp //stuff //remote/stuff
With this copy you practically lose your history in the backup (ideas?). At this point, every time I want to backup, I issue:
shell$ svk smerge -lI //stuff //remote/stuff
In this way I get all commit messages correctly mirrored, because I'm asking to use available logs (-l) in incremental form (-I).
The setup for a local backup is a little different. I "live" in Linux, but backup on both a disk server accessible via SMB and my USB pen (FAT32 formatted), so I keep a local file that has a filesystem and copy it when I need. Basically I have this in my fstab:
/path/to/mirror.ext3 /mnt/backup ext3 loop,user,noauto 0 0
so that I can
shell$ mount /mnt/backup
I then use an ad-hoc depot:
shell$ svk depotmap -l | grep backup /backup/ /mnt/backup/Flavio/svk
where I keep the backup:
shell$ svk mirror file:///home/poletti/.svk/local /backup/local shell$ svk sync /backup/local
The last command is also the one I issue each time I want to refresh the backup. I then unmount the file, zip it and put where I want to keep it.
So, after setting it all up, the only commands that I run when I want to backup are:
shell$ svk smerge -lI //stuff //remote/stuff shell$ svk sync /backup/local
-- Flavio Poletti