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 ?
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".
If you're running SVK on your local machine the equivalent of the above would be:
# 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 file:///home/user/.svk/local/repos/path # pull new changes from the main repository mirror$ svk sync //mirror/repos mirror$ svk smerge //mirror/repos //local/repos # to commit changes from mirror to the main repository: svk sync //mirror/repos svk smerge -C //local/repos //mirror/repos #(resolve conflicts if any) svk smerge //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, and you could just as easily call it [=//ProjectName] or even //mirror/repos-local, the important point is svn isn't interacting with anything under the //mirror/repos directory. -- SamHasler