Kash Farooq's software development blog

.NET Developer

Posts Tagged ‘SVN’

Bazaar branching strategy with a subversion trunk – revised

Posted by Kash Farooq on December 16, 2010

This blog post will describe how our team ended up working with BZR and SVN.
We had to make some changes as the the method described in Bazaar branching strategy with a subversion trunk as this method made branching an expensive operation.

First we created a BZR repository on a shared server and made a branch of the SVN code:

bzr init-repo c:\bzr\SharedRepo
cd \bzr\SharedRepo
bzr branch svn://localhost/trunk --no-tree

This creates the directory c:\bzr\SharedRepo\trunk with nothing in it apart from the .bzr hidden folder.

If we wanted to work on a branch we would create a no-tree branch from the trunk. This is an incredibly fast operation:

cd c:\bzr\SharedRepo
bzr branch trunk feature_branch1 --no-tree
bzr branch trunk feature_branch2 --no-tree

This creates the directories c:\bzr\SharedRepo\feature_branch1 and c:\bzr\SharedRepo\feature_branch2, again with nothing in it apart from the .bzr hidden folder.

Now, on our development computers we also create a BZR repository and “connected” to the branches to the shared server:

cd dev
bzr init-repo MyRepo
cd MyRepo
bzr branch \\server\SharedRepo\trunk MyRepo\trunk --no-tree
bzr branch \\server\SharedRepo\feature_branch1 MyRepo\feature_branch1 --no-tree
bzr branch \\server\SharedRepo\feature_branch2 MyRepo\feature_branch2 --no-tree

We still haven’t actually got the code yet!
The finally step is as follows (and the example below sets us up to work on feature 1)

cd \dev
mkdir current
bzr checkout MyRepo\trunk trunk
bzr checkout MyRepo\feature_branch1 current

Now we can see source code in c:\dev\trunk and c:\dev\current.
We can work on, say, feature 1, commit code locally, push back to the shared server:

....after some dev.....
cd c:\dev\current
bzr commit -m "My commit comment"
bzr push  \\server\SharedRepo\feature_branch1 --remember

If we need to switch to working on feature 2:

cd c:\dev\current
bzr switch ..\MyRepo\feature_branch2

This will sync c:\dev\current so that it now matches feature_branch2. Any files you have added in feature_branch1 will be removed.
Any files that are in feature_branch2 but not in feature_branch1 will be added. Basically “current” will look like feature_branch2 now.

Once dev is complete and code has been pushed back to the shared server, and you want to merge back into the trunk:

cd c:\dev\trunk
bzr merge \\server\SharedRepo\feature_branch2
bzr commit -m "merged feature 2"
bzr push \\server\SharedRepo\trunk

Then we can hop onto the shared server and push back to SVN

cd c:\bzr\SharedRepo\trunk
bzr push svn://localhost/trunk

The basic rule we observed for the interaction with SVN was to never push to the SVN trunk except from the BZR trunk.

Posted in Bazaar Source Control | Tagged: , , , | Leave a Comment »

Using Bazaar feature branches with a Subversion trunk

Posted by Kash Farooq on November 2, 2009

If your corporate strategy is to store source code in Subversion, but you are having merge and other Subversion problems, this is the blog post for you.

I have already listed some of the issues we were having and why we decided to move away from Subversion.

In this blog post, I’ll show how you can have a Subversion trunk but do your day-to-day development in a Bazaar feature branch.
This is all possible thanks to the Subversion plugin for Bazaar. The plugin is installed by default when you install the latest Bazaar Windows standalone package.

Here’s the example I’m going to demonstrate:

  1. Create a feature Bazaar branch from a subversion Trunk. This branch will be created in a shared location.
  2. Create a local branch this Bazaar branch.
  3. Work on the local branch, committing changes and pushing them back to the shared branch.
  4. Once the feature is complete, push changes back to the Subversion trunk.

The initial Bazaar feature branch is created in a shared location so that multiple developers can work on the feature.

Setting up

First I creat a Subversion repository, and start svnserve to serve it.

svnadmin create c:\dev\svn_repo
svnserve -d -r c:\dev\svn_repo

Then in another command prompt, I do a checkout:

svn checkout svn://localhost c:\dev\svn_checkout

Now I can add some sample code to this Subversion trunk and commit it back to the repository. [In my case, I added some sample code for a couple of design patterns.]

Create a shared bazaar feature branch

Now I will use the Bazaar Subversion plugin to create a Bazaar feature branch. I’ll do this in a shared location so that multiple developers can work on it.

cd c:\dev\bzr_svn_branch
bzr branch svn://localhost/Observer \\my_server\bzr_branches\update_design_pattern\Observer

The Subversion plugin is automatically used as I have given a SVN URI.
If you are using a Subversion repository that is accessed via HTTP, the branch command would be:

bzr branch svn+http://webserver/Observer \\my_server\bzr_branches\update_design_pattern\Observer

You need to add “svn+” so Bazaar knows that you are not accessing a Bazaar repository via HTTP.

Create a local branch to work on

Now I can create a local branch from the shared branch. This is much like working from a Bazaar repository located on, say, a USB Drive.

cd c:\dev\bzr_branch
bzr branch \\my_server\bzr_branches\update_design_pattern\Observer

This creates a local branch from the shared branch at c:\dev\bzr_branch\Observer.

You can now develop on your local branch. When you commit, you will just be committing locally.
All developers working on this feature should regularly pull from and push back to the central shared branch.

bzr pull \\my_server\bzr_branches\update_design_pattern\Observer
bzr commit
bzr push \\my_server\bzr_branches\update_design_pattern\Observer

Note – you only need to give the full path to the shared branch the first time you use the pull or push commands. Bazaar will remember it for subsequent pull/push commands.

Pushing back to the Subversion trunk

Once development is complete, you will want to push your shared Bazaar branch back to the Subversion trunk.
You have a number of options:

  1. Logon to the shared server and push back from there.
  2. Map a drive to the shared location so you can open a command prompt at, say, e:\.
  3. Pull the latest shared branch locally and push back from your there.

Whatever option you take, the commmand is simply:

cd e:\dev\bzr_branches\update_design_pattern\Observer
bzr push svn://localhost/Observer

If you have renamed and moved files in your Bazaar branch, the Subversion plugin will issue the appropriate Subversion delete and add commands.

Posted in Bazaar Source Control | Tagged: , , , | Leave a Comment »

Bazaar or Git? Moving away from Subversion.

Posted by Kash Farooq on September 8, 2009

I’ve had enough of Subversion and decided to move to Bazaar. Click BZR in the Tag Clould to see my series of blog posts to help you do the same.

Do any of these Subversion complaints sound familiar?

  • You are randomly instructed that “you need to run update”. You then do an update – which takes ages to complete. And then, finally, you see that there were no changes that needed to be downloaded.
  • You are randomly instructed that “you need to run cleanup”.
  • You have huge merge problems. For example, you use ReSharper to rename a class, and some else has updated that class in the meantime. You then see the dreaded tree conflict error (shudder). Or even worse, you rename an entire namespace and folder (double shudder). Now you really are in for a world of pain.
  • Your merges tend to be more and more manual. You frequently have to use WinMerge because Subversion hasn’t got a clue.
  • You are often waiting around for Tortoise to update/check for modifications/anything.

I have a subversion repository on my USB pen drive. I get tree conflicts and merge problems with that, and I’m the only user!

The main problem is merging. Our team has to work on branches as we have different projects running concurrently, working on the same code base. We don’t know which project will be going live first, or even if the project will be released at all (they may get canned). So, we need an efficient merging process.

Merging has become so problematic that we’ve considering adding merging as a separate task for each MMF we implement – that’s how long it takes nowadays. We’ve even considered putting a “Work In Process” limit on particular pieces of code to make sure two unrelated MMFs don’t touch the same code.

[Can you tell that I am not happy with Subversion?]

So, I decided to try something else.

I was going to try Git. I downloaded binaries, documentation and guides. But then I read this article: Renaming is the killer app of distributed version control. And I agree, renaming is really, really important. We rename files all the time. We refactor.

Git doesn’t handle renames as a “first class operation” – renames are just a delete operation followed by an add operation. This is the same as Subversion. I assume Git handles it much better than Subversion, but I wanted a SCM that has it built in.

So, I decided to start using Bazaar: renames are a first class operation in Bazaar, and it also has “Intelligent Merging” to cope with your Dev Studio file moves or renames.

For a full feature list of a number of SCM systems see this source control comparison page.

So far, I’m happy:

  • It runs natively in windows (I didn’t really want to run a unix-type shell to get Git working).
  • It is easy to work with from the command line (I thought I’d miss Dev Studio integration, e.g. VisualSVN and Ankh, but I don’t).
  • I even decided not to install TortoiseBZR – you don’t need it. [Tortoise is one of the reasons I wanted to move away from Subversion so I didn’t want to install the BZR equivalent.]
  • BZR comes with some GUI applets if you really need your GUIs. For example, there is a useful one for viewing change logs (command: “bzr qlog”)

To make the move, check out getting started with Bazaar source control.

Posted in Bazaar Source Control | Tagged: , , , , | 4 Comments »