Relocating svk mirrors

2005-10-22T12:37:00+00:00

When I created my svk mirrors I used http to connect to my svn repository. However since then I activated https support on my server. Due to some stupidity on my part (and how hard it is to debug webserver configuration problems) I didn’t get it to work until this week (thanks to the TextDrive support). To relocate a mirror you should just have to do like this:

C:\>svk mirror --list
Path                    Source
============================================================
//andthennothing        http://urltorepository
//typo/mirror           svn://leetsoft.com/typo/trunk
C:\>svk mirror --relocate //andthennothing https://urltorepository

But I wouldn’t write this if it was that painless. I got this error instead:

C:\>svk mirror --relocate //andthennothing https://urltorepository
Error validating server certificate for 'https://hostname:443':
<snip />
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Type error in argument 2 of svn_auth_cred_ssl_server_trust_t_accepted_failures_set. Expected _p_apr_uint32_t at C:/Development/svk/lib/SVN/Base.pm line 80, <STDIN> line 1.

After a while of searching darix at the #svn helped me out.

C:\>svn ls https://urltorepository
Error validating server certificate for 'https://hostname:443':
<snip />
(R)eject, accept (t)emporarily or accept (p)ermanently? p
branches/
trunk/
C:\>svk mirror --relocate //andthennothing https://urltorepository
Authentication realm: <https://hostname:443> realm
Password for 'user':
Committed revision 633.
C:\>svk mirror --list
Path                    Source
============================================================
//andthennothing        https://urltorepository
//typo/mirror           svn://leetsoft.com/typo/trunk

Yay! So I guess there’s some problems with adding a certificate through svk at least on Windows (more specifically svn’s Perl bindings on Windows). But as soon as the certificate is cached (through svn) everything works fine.

I feel so much secure now using https instead of http :-)

Update: To relocate a svn checkout you just type svn switch https://urltorepository. Easy peasy!

Handling multiple repositories with svn and svk

2005-10-01T19:46:00+00:00

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: Tag svk

Relocating svk mirrors

Handling multiple repositories with svn and svk