&ldquo;first there was a three-legged monkey...&rdquo; tag:andthennothing.net,2005:Typo Typo 2005-12-18T03:19:00+00:00 Jonas Bengtsson urn:uuid:264bd84e-1ae4-4092-8da0-a33911a16f14 2005-11-08T09:44:58+00:00 2005-12-18T03:19:00+00:00 I'm glad to hear that! Eric Davis urn:uuid:ba957a16-c77a-4985-8eee-a88c711d104f 2005-11-08T03:45:43+00:00 2005-12-18T03:19:00+00:00 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 Jonas Bengtsson jonas.b@home.se urn:uuid:3067c42b-7001-4a39-b07d-b5a8d0441256 2005-10-01T19:46:00+00:00 2005-12-18T03:19:02+00:00 <p>On a day-to-day basis I&#8217;m using <a href="http://www.perforce.com/">Perforce</a> at work for my <acronym title="Software Configuration Management">SCM</acronym> needs. I&#8217;ve used <a href="http://www.cvshome.org">CVS</a> a few times back in the days but I&#8217;ve tried to forget about it :-). But as I&#8217;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.</p> <p>I asked at the <a href="http://typo.leetsoft.com/">Typo</a> mailing list, and a similar thread appeared on the <a href="http://www.rubyonrails.org/">Rails</a> mailing list, and the general recommendation was to use <a href="http://svk.elixus.org/">svk</a> (especially <a href="http://article.gmane.org/gmane.comp.lang.ruby.rails/23701">this mail</a> won me over). Other reference material I used was <a href="http://scottstuff.net/blog/articles/2005/07/07/distributed-development-with-svk">this</a>, <a href="http://svk.elixus.org/">that</a>, and <a href="http://svnbook.red-bean.com/">the other</a>. This is a writeup of how I went about <em>(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&#8217;t understand)</em>:</p> <p>Installing svk from <a href="http://svk.elixus.org/?SVKWin32">here</a>.</p> <div class="typocode"><pre><code class="typocode_default ">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</code></pre></div> <p>Seems to work.</p> <p>I&#8217;m a little bit worried at this stage. I&#8217;d like to use the <a href="http://www.eclipse.org/">Eclipse</a> plugin <a href="http://subclipse.tigris.org">subclipse</a> when developing. Perhaps I should only use svk when migrating between different trees. Yes, I think I&#8217;ll go for that, and to make it smooth I&#8217;ll keep all svk checkouts (<code>svk co --list</code>) in one directory called <code>svk</code>. So let&#8217;s relocate:</p> <div class="typocode"><pre><code class="typocode_default ">svk co --relocate typo-mirror svk\typo-mirror</code></pre></div> <p>I might change my mind further down the line and want to use svk exclusively, but I don&#8217;t expect that to be a problem since svk appears to be quite flexible.</p> <p>Time to move into svn land. I need to create a trunk and a development tree on my Textdrive repository.</p> <div class="typocode"><pre><code class="typocode_default ">svn mkdir http://urltorepository/trunk svn mkdir http://urltorepository/branches svn mkdir http://urltorepository/branches/dev</code></pre></div> Time to chechout the svn branches: <div class="typocode"><pre><code class="typocode_default ">svn co http://urltorepository/trunk site-trunk svn co http://urltorepository/branches/trunk site-dev</code></pre></div> <p>Back in svk land.</p> <div class="typocode"><pre><code class="typocode_default ">svk mirror http://urltorepository //site svk sync //site svk co //site/branches/dev site-dev</code></pre></div> <p>Time to do a baseless merge from Typo to the dev branch:</p> <div class="typocode"><pre><code class="typocode_default ">svk smerge --baseless //typo/mirror site-dev</code></pre></div> <p>Since the dev branch was empty before it&#8217;s safe to commit the changes without reviewing: <code>svk commit</code>.</p> <p>Time to update Typo with the changes I&#8217;ve done previously. <code>svn update</code> in my site-dev checkout. Firing up a favourite open source utility of mine: <a href="http://winmerge.org/">WinMerge</a>. Takes a while to merge all the files, but now I&#8217;m done, just have to try out if it works alright. It seems to work fine. <code>svn status</code>. Hmm, most of my customizations of Typo is in the views, and looking at this <a href="http://typo.leetsoft.com/trac/ticket/354">ticket</a> Typo is apparently supporting themed views, have to try it out&#8230; Yes it works, neato! <code>svn add</code> on all the new files and <code>svn commit</code>.</p> Back to svk to integrate to the trunk. <div class="typocode"><pre><code class="typocode_default ">svk sync //site svk co //site/trunk andthennothing-trunk</code></pre></div> Migrating from the dev branch to trunk: <div class="typocode"><pre><code class="typocode_default ">svk smerge --baseless //site/branches/dev site-trunk svk commit</code></pre></div> <p>I think that&#8217;s it and hope it will be quite easy to manage in the future. There are two main cycles I&#8217;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&#8217;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&#8217;m used to working with a lot of different branches (release, import, team, personal etc.) so that&#8217;s how I&#8217;m feeling comfortable at the moment. But it will probably be quite easy to remove the dev branch if deemed unnecessary.</p> <p>Both svn and svk are new and welcomed acquaintances. Working in the command prompt with <span class="caps">SCM</span> 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&#8217;m somewhat worried that it will be cumbersome). svn&#8217;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.</p> <p>Nice learning experience!</p>