"Handling multiple repositories with svn and svk" by Jonas Bengtsson

Tue, 08 Nov 2005 09:44:58 +0000

I'm glad to hear that!

"Handling multiple repositories with svn and svk" by Eric Davis

Tue, 08 Nov 2005 03:45:43 +0000

Thanks for this, it was what I needed to setup my repository structure. I can now pull updates down from upstream, play around with it and apply my own patches in my local svk branch and finally push the update to my own svn repo. Eric

Handling multiple repositories with svn and svk

jonas.b@home.se (Jonas Bengtsson) — Sat, 01 Oct 2005 19:46:00 +0000

On a day-to-day basis I’m using Perforce at work for my SCM needs. I’ve used CVS a few times back in the days but I’ve tried to forget about it :-). But as I’m migrating to my new web host I have to learn how to use Subversion (svn). The main issue I saw was how to manage multiple branches and repositories.

I asked at the Typo mailing list, and a similar thread appeared on the Rails mailing list, and the general recommendation was to use svk (especially this mail won me over). Other reference material I used was this, that, and the other. This is a writeup of how I went about (it might not be that easy to understand and a little more explanations are probably needed for this to be helpful, but just ask me if there is something that you don’t understand):

Installing svk from here.

svk depotmap --init
svk mkdir //typo
svk mirror svn://leetsoft.com/typo/trunk //typo/mirror
svk sync //typo/mirror
svk co //typo/mirror typo-mirror

Seems to work.

I’m a little bit worried at this stage. I’d like to use the Eclipse plugin subclipse when developing. Perhaps I should only use svk when migrating between different trees. Yes, I think I’ll go for that, and to make it smooth I’ll keep all svk checkouts (svk co --list) in one directory called svk. So let’s relocate:

svk co --relocate typo-mirror svk\typo-mirror

I might change my mind further down the line and want to use svk exclusively, but I don’t expect that to be a problem since svk appears to be quite flexible.

Time to move into svn land. I need to create a trunk and a development tree on my Textdrive repository.

svn mkdir http://urltorepository/trunk
svn mkdir http://urltorepository/branches
svn mkdir http://urltorepository/branches/dev

Time to chechout the svn branches:

svn co http://urltorepository/trunk site-trunk
svn co http://urltorepository/branches/trunk site-dev

Back in svk land.

svk mirror http://urltorepository //site
svk sync //site
svk co //site/branches/dev site-dev

Time to do a baseless merge from Typo to the dev branch:

svk smerge --baseless //typo/mirror site-dev

Since the dev branch was empty before it’s safe to commit the changes without reviewing: svk commit.

Time to update Typo with the changes I’ve done previously. svn update in my site-dev checkout. Firing up a favourite open source utility of mine: WinMerge. Takes a while to merge all the files, but now I’m done, just have to try out if it works alright. It seems to work fine. svn status. Hmm, most of my customizations of Typo is in the views, and looking at this ticket Typo is apparently supporting themed views, have to try it out… Yes it works, neato! svn add on all the new files and svn commit.

Back to svk to integrate to the trunk.

svk sync //site
svk co //site/trunk andthennothing-trunk

Migrating from the dev branch to trunk:

svk smerge --baseless //site/branches/dev site-trunk
svk commit

I think that’s it and hope it will be quite easy to manage in the future. There are two main cycles I’ll be performing. One is getting updates from the Typo repository, and then migrate the changes to the dev branch to the trunk. The other one is migrating changes I’m doing to the dev branch to the trunk. Both of those should be quite easy to manage in svk. I think that the dev branch might be unnecessary, but I’m used to working with a lot of different branches (release, import, team, personal etc.) so that’s how I’m feeling comfortable at the moment. But it will probably be quite easy to remove the dev branch if deemed unnecessary.

Both svn and svk are new and welcomed acquaintances. Working in the command prompt with SCM tools were nicer than I thought and remembered. Hopefully I will have the same opinion in a couple of weeks when I have a little more experience with merging and resolving conflicts (I’m somewhat worried that it will be cumbersome). svn’s poor support for branches and merging is my main pet peeve, but svk handled that nicely. I would go for a svk only (on the client side) if there were a Eclipse plug-in.

Nice learning experience!

andthennothing.net: Handling multiple repositories with svn and svk

"Handling multiple repositories with svn and svk" by Rolex Watches

"Handling multiple repositories with svn and svk" by Jonas Bengtsson

"Handling multiple repositories with svn and svk" by Eric Davis

Handling multiple repositories with svn and svk