Bazaar branching strategy with a subversion trunk – revised

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.

Bazaar branching strategy with a Subversion trunk

Edit: This post has been superseded by Bazaar branching strategy with a subversion trunk – revised

When creating a feature branch from a Subversion trunk, there are a few things to be aware of.

Consider the following Subversion repository structure representing components that are independently releasable:

trunk
  WebService1
  WebService2
  WindowsService1
  WindowsService2
  UiApp1

With this repository I am suggesting it is completely reasonable to release, say, just UiApp1 without releasing any web or windows services.

With Subversion I could create a feature branch as follows:

branches
  MyFeature
    WebService1
    WebService2
    WindowsService1
    WindowsService2
    UiApp1

Then, if MyFeature actually only needed changes made to WindowsService2, I can safely just merge WindowsService2 back into the trunk – i.e. I would use TortoiseSVN to right click on trunk\WindowsService2 and merge from branches\MyFeature\WindowsService2.

Things are different in the Bazaar world: you can only merge/pull/push from the level you branched at.
If you created a branch like the one above using Bazaar, you would have to merge/pull/push the entire branch – i.e. at the same level as your .bzr folder.

Why is this a problem?
Well, if you know that you have only changed WindowsService2, you can’t just push that back to the trunk. You have to push all folders back into the trunk. The problem arises if someone else has changed, say, WebService2 in the trunk. Bazaar will make you merge those changes into your branch first before you can push your branch back.

Example scenario (this situation happened in our team):

• Developer 1 creates MyFeature branch and works on WindowsService2 only.
• Developer 2 creates TheirFeature branch and works on UiApp1 only.
• Developer 2 commits change back to trunk and creates TheirFeature_Phase2 branch.
• Developer 1 attempts to commit change back to trunk. Bazaar says a merge in needed (even though Developer 1 hasn’t touched UiApp1).
• Developer 1 does the merge and pushes the branch back to the trunk.
• Now Developer 2 attempts to push back to the trunk – Bazaar says UiApp1 has changed even though only Developer 2 has worked on this bit of code!
• Developer 2 has to merge before pushing back to the trunk.

So, there are a few pain points here. From commit logs it appears as though MyFeature changed UiApp1 when it didn’t.
Both developers had to do unnecessary, potentially confusing merges.

So, to get around this issue, we now create branches at “component level”.
If MyFeature only needs to work on, say WebService1 and WindowsService2, we only create branches for those components.

The full feature branch area on the shared server may look like this:

branches
  MyFeature
    WebService1
	  .bzr
    WindowsService2
	  .bzr
  TheirFeature
    UiApp1
	  .bzr

Now we only have to push back the code that we have actually changed.

This strategy has been successful on our team – we use the great Bazaar features to make our renames/refactors/merges simple, and with just a small amount of extra branch creation work we can keep our synchronisation back to the trunk at the right level.

Bazaar SVN plugin and the append_revisions_only error

If you try to push changes from your Bazaar feature branch back to a Subversion repository, and the Subversion repository has been changed since you created your Bazaar branch, you may get something like this:

bzr push
Using saved push location: svn+http://svn/repos/Trunk/MyProject
bzr: ERROR: Operation denied because it would change the mainline history. Set the append_revisions_only setting to False on branch "svn+http://svn/repos/Trunk/MyProject" to allow the mainline to change.

The current version of Bazaar on Windows does not give you much information on where you have to do this.

This is what I did to allow me to push code back into Subversion.
Find subversion.conf. It is located at:

1. Windows Vista: C:\Users\your-user-name\AppData\Roaming\bazaar\2.0\
2. Windows XP/2003: C:\Documents and Settings\your-user-name\ApplicationData\bazaar\2.0\

Inside this file you’ll see something like this:

[4ef181b9-d188-42c4-ae88-5d15bdaece0b]
locations = svn+http://svn/repos/Trunk/MyProject

Simply change the file to:

[4ef181b9-d188-42c4-ae88-5d15bdaece0b]
locations = svn+http://svn/repos/Trunk/MyProject
append_revisions_only = False

Using Bazaar feature branches with a Subversion trunk

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.

Integrate Bazaar Source Control with your preferred merge application

I have shown how you can use any merge tool with Bazaar to deal with conflicts. In this blog post I’ll show how you can get a more integrated experience.

Bazaar 2.0 introduced a handy application called Bazaar Explorer. You can use it to issue most of the everyday commands you will use with Bazaar. You can also use it to quickly fix your conflicts.

First, configure Bazaar so it knows how to launch your favourite merge tool.
Open up C:\Documents and Settings\YourUserName\Application Data\bazaar\2.0\bazaar.conf.
Now add a reference, with appropriate command line options, to a merge tool. I like Tortoise Merge, so to the DEFAULT section I added the line:

[DEFAULT]
external_merge = tortoisemerge /base:%b /theirs:%o /mine:%t /merged:%r

Now open up Bazaar Explorer with the command:

bzr explorer

Click File, then Open, and then navigate to the location of your bzr checkout/branch – i.e. to the location with the .bzr folder.
My branch contains a conflict so I see the following:

Now, let’s fix that conflict:

Click the Resolve Conflicts menu option and Bazaar explorer will launch qconflict (i.e. Bazaar explorer will issue the command “bzr qconflicts”):

Select the “Use Configured Default” check box at the bottom of the dialog and you will see the text we added earlier to the bazaar.conf file.

Now it is a simple case of highlighting the file you want to edit, and then clicking the launch button. In my case, this will fire up TortoiseMerge.

After you have fixed the conflict, right click the file to tell Bazaar (i.e. issue the “bzr resolve” command):

Bazaar Source Control: subvertpy.tmp and the access is denied error

Update: I’ve just installed Bazaar version 2.0.2-1 and this error didn’t occur.

When creating a Bazaar branch from a Subversion repository, part way through the file transfer, I’d often get an error like the following:

bzr: ERROR: [Errno 5] Can't open 'C:\DOCUME~1\MyUsername\LOCALS~1\Temp\subvertpy.tmp': Access is denied.

The only fix I could find was to delete the partially downloaded branch and try again. This becomes very tedious if you get the same error several times…

I have finally figured out what is happening. It is my virus checker.
I haven’t looked at the code for the Bazaar svn plugin, but I assume the plugin is trying to delete (or get an exclusive lock on) the subvertpy.tmp temporary file whilst the virus checker is trying to scan it.

So, the fix is to simply add this file to your virus checker exclude list.

Merge Tools and Bazaar Source Control

Continuing on from where handling conflicts in Bazaar Source Control left off, this blog post shows some of the options you have for helping you resolve conflicts.

Once you’ve used one of the methods to resolve your conflicts, remember to tell Bazaar that you have resolved them using the “bzr resolve” command.

TortoiseMerge

Yes, yes, I know. I’ve been slagging off Subversion and Tortoise and now I’m using it to help me do my Bazaar merges. Well, I can admit that the conflict resolution tool is pretty good. And you can run it standalone.

So, install TortoiseSVN, don’t bother rebooting, go to C:\Program Files\TortoiseSVN\bin and fire up TortoiseMerge.exe.

You will be presented with this dialog:

And now it should be obvious. Set:

• “Base File” to SystemUnderTest.cs.BASE
• “Their File” to SystemUnderTest.cs.OTHER
• “My File” to SystemUnderTest.cs.THIS

After doing this and clicking OK you will see a three-way merge dialog (click to see full image):

The bottom panel is the target file.
Make your updates, click save and then tell Bazaar that you have resolved the conflict.

Winmerge

A simple option is to use Winmerge. Install Winmerge, go to explorer, right click SystemUnderTest.cs and click Winmerge.

You get a the Winmerge dialog (click to see full image):

Winmerge can only do a “two way merge”. The panel on the left shows PersonA’s changes. The panel on the right shows PersonB’s changes.
The panel on the right is also the current target file – if I click “Save” right now, this is the file that I would end up pushing back to the central shared Bazaar repository.
You can make any changes you want to in this right hand side panel: you can type directly into it, copy and paste into it, or copy from left panel to right panel.

Conflicts in Bazaar Source Control

In merging files with Bazaar Source Control I made sure I didn’t get any conflicts by adding the two methods strategically! Of course, in real life we often will get conflicts. This blog post will demonstrate how to deal with them.

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

1. Two people create a personal branch from a shared repository.
2. Person A adds changes MyMethod in SystemUnderTest.cs.
3. Person B also changes MyMethod in a conflicting way.
4. Person A commits and pushes to the shared repository.
5. Person B then tries to push to the shared repository.

This will result in a text conflict.

Setting up

PersonA and PersonB make local branches of the shared repository:

C:\Dev\bazaar_branches\PersonA>bzr branch \myserver\shared_bzr_repo MyBranch
cd. ..\PersonB
C:\Dev\bazaar_branches\PersonB>bzr branch \myserver\shared_bzr_repo MyBranch

First, one developer updates a method…

The method that both developers will change:

public void MyMethod() {
  smtpClient.Send(new MailMessage {Subject = "Hello!"});
}

First, PersonA changes the method:

public void MyMethod() {
  smtpClient.Send(new MailMessage {Subject = "Person A says hi!"});
}

Now PersonA commits and pushes back to the shared location:

C:\Dev\PersonA\Shared>bzr status
modified:
  SystemUnderTest.cs

C:\Dev\PersonA\Shared>bzr commit
Committing to: C:/Dev/PersonA/Shared/
modified SystemUnderTest.cs
Committed revision 2.

C:\Dev\PersonA\Shared>bzr push \myserver\shared_bzr_repo
All changes applied successfully.
Pushed up to revision 2.

Introducing a conflict

PersonB changes the same method:

public void MyMethod() {
  smtpClient.Send(new MailMessage {Subject = "Person B says hello there!"});
}

Now, after commiting and then attempting to push back to the shared repository, the following message is given:

C:\Dev\PersonB\Shared>bzr push \myserver\shared_bzr_repo
bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.

Let’s try to pull the changes down:

C:\Dev\PersonB\Shared>bzr pull
bzr: ERROR: These branches have diverged. Use the missing command to see how.
Use the merge command to reconcile them.

Okay, let’s do a merge:

C:\Dev\PersonB\Shared>bzr merge
Merging from remembered parent location //myserver/shared_bzr_repo
 M  SystemUnderTest.cs
Text conflict in SystemUnderTest.cs
1 conflicts encountered.

Examining the conflict

Let’s look at the list of conflicts:

C:\Dev\PersonB\Shared>bzr conflicts
Text conflict in SystemUnderTest.cs

So, we have a text conflict. If we look at the directory, we can see the following files:

C:\Dev\PersonB\Shared>dir /b
SystemUnderTest.cs
SystemUnderTest.cs.BASE
SystemUnderTest.cs.OTHER
SystemUnderTest.cs.THIS

Some definitions:

1. The .BASE file: This is the original file without PersonA or PersonB’s (“Hello!”)
2. The OTHER file: This contains PersonA’s changes (“Person A says hi!”)
3. The THIS file: This contains PersonB’s changes (“Person B says hello there!”)
4. The .cs file: See below.

Opening SystemUnderTest.cs shows us the location of the conflicts and the differences between PersonA and PersonB’s changes:

public void MethodUnderTest() {
<<<<<<< TREE
  smtpClient.Send(new MailMessage {Subject = "Hello there"});
=======
  smtpClient.Send(new MailMessage {Subject = "Hi"});
>>>>>>> MERGE-SOURCE
}

You may recognise the above format, along with the .OTHER and .THIS files, from other source control systems. Basically, this means you can use a number of tools to deal with the conflict.

Dealing with conflict

At this point you have a manual step. You can:

1. Option 1: Edit SystemUnderTest.cs by hand.
2. Option 2: Fire up a merge tool to help you deal with the conflicts.

Whichever method you choose, after you have completed this task, you need to tell Bazaar and then you can commit and push back to the shared repository:

bzr resolve SystemUnderTest.cs
bzr commit
bzr push

Merging files with Bazaar Source Control

This blog post is a more complex example of renaming files with Bazaar Source Control.

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

1. Two people create a personal branch from a shared repository.
2. Person A adds a method to MyTest.cs.
3. Person B also adds a method to MyTest.cs, but also moves it to a new namespace folder called Tests, and, why not, Person B also renames the class and file.
4. Person A commits and pushes to the shared repository.
5. Person B then tries to push to the shared repository.

The above would really make SVN scream and give up. [I would be interested to hear how Git would handle the above situation, please send me your comments.]

Setting up

Let’s start with directory structure that will hold a shared repository and two directories representing two developers:

 Directory of C:\Dev\bazaar_branches

28/09/2009  21:00    <DIR>          .
28/09/2009  21:00    <DIR>          ..
28/09/2009  20:58    <DIR>          PersonA
28/09/2009  20:59    <DIR>          PersonB
28/09/2009  21:00    <DIR>          Shared

Initialize Shared as a Bazaar repository:

cd Shared
bzr init

This results in the message:

Created a standalone tree (format: pack-0.92)

Now put some sample code to the Shared directory, add it, then commit it:

bzr add
bzr commit

Which gives:

Committing to: C:/Dev/bazaar_branches/Shared/
added BazaarRenames
added BazaarRenames/BazaarRename.csproj
added BazaarRenames/UnitTests
added BazaarRenames/Properties/AssemblyInfo.cs
added BazaarRenames/UnitTests/MyTest.cs
Committed revision 1.

Now PersonA and PersonB can make local branches of the shared repository:

cd ..\PersonA
C:\Dev\bazaar_branches\PersonA>bzr branch ..\Shared MyBranch
cd. ..\PersonB
C:\Dev\bazaar_branches\PersonB>bzr branch ..\Shared MyBranch

Two developers update the same file

PersonA will now add a method to MyTest, commit it and then push it back to the Shared repository. I’ll call it PersonATest so we can see it clearly at the end of this blog post.

C:\Dev\bzr_branches\PersonA\MyBranch>bzr commit
Committing to: C:/Dev/bzr_branches/PersonA/MyBranch/
modified BazaarRenames/UnitTests/MyTest.cs
Committed revision 2.

C:\Dev\bzr_branches\PersonA\MyBranch>bzr push ..\..\Shared
All changes applied successfully.
Pushed up to revision 2.

PersonB will also change this same class.
PersonB adds a new folder called TestCases, moves the test class to this directory, renames the test file and then adds a new method. I’ll call the new method PersonBHas_RenamedTheClass_MovedIt_AndAddedATest so, again, we can see it clearly at the end of this blog post:

C:\Dev\bzr_branches\PersonB\MyBranch>bzr add --no-recurse
adding BazaarRenames/TestCases

C:\Dev\bzr_branches\PersonB\MyBranch>bzr mv --auto
BazaarRenames/UnitTests/MyTest.cs => BazaarRenames/TestCases/SystemTests.cs

C:\Dev\bzr_branches\PersonB\MyBranch>bzr commit
Committing to: C:/Dev/bzr_branches/PersonB/MyBranch/
added BazaarRenames/TestCases
renamed BazaarRenames/UnitTests/MyTest.cs => BazaarRenames/TestCases/SystemTests.cs
Committed revision 2.

Merging the two sets of changes

Now PersonB tries to push this back to Shared:

C:\Dev\bzr_branches\PersonB\MyBranch>bzr push ..\..\Shared

This results in the following message:

bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.

Bazaar knows that PersonB cannot just push the changes back. Let’s pull the changes from Shared to see what has happened:

C:\Dev\bzr_branches\PersonB\MyBranch>bzr pull

This results in the following message:

Using saved parent location: C:/Dev/bzr_branches/Shared/
bzr: ERROR: These branches have diverged. Use the missing command to see how.
Use the merge command to reconcile them.

Bazaar is informing you that PersonB cannot just pull the changes – a merge is needed. So, let’s run the merge command:

C:\Dev\bzr_branches\PersonB\MyBranch>bzr merge

This results in the following message:

Merging from remembered parent location C:/Dev/bzr_branches/Shared/
 M  BazaarRenames/TestCases/SystemTests.cs
All changes applied successfully.

[/sourcecode]

That’s it – Bazaar has not only kept track of the fact that PersonB renamed and moved the file, it has also done the merge – PersonA’s changes have been merged into the new location and for the file.
In my example, I didn’t get any conflicts. [In another blog post I will look at dealing with conflicts]
With my code samples the resultant test file in the TestCases folder looks like this:

[TestFixture]
public class SystemTests {
	[Test]
	public void PersonATest() {
		//Here is PersonA's test
		Assert.That(1, Is.EqualTo(1));
	}

	[Test]
	public void SomeOtherCode() {
		//
	}
	
	[Test]
	public void PersonBHas_RenamedTheClass_MovedIt_AndAddedATest() {
		Console.WriteLine("Person B changed");
	}
}

Our final step is for PersonB to commit the merge results and push them back to the Shared repository:

C:\Dev\bzr_branches\PersonB\MyBranch>bzr commit
Committing to: C:/Dev/bzr_branches/PersonB/MyBranch/
modified BazaarRenames/TestCases/SystemTests.cs
Committed revision 3.

C:\Dev\bzr_branches\PersonB\MyBranch>bzr push ..\..\Shared
All changes applied successfully.
Pushed up to revision 3.

Renaming files and folders with Bazaar Source Control

Following on from Getting started with Bazaar Version Control, now we’ll look at the Holy Grail of Source Control: Renaming files. After all, that’s why we’re ditching Subversion.

A simple file rename

In your BZR controlled local branch, pick a class and use Resharper to rename it (and the .cs).

Run the command:

bzr status

You get output like this:

removed:
  myproj/src/MyTest.cs
modified:
  myproj/src/myproj.csproj
unknown:
  myproj/src/MyRenamedTest.cs

BZR has found that the project file has changed, one file is missing and that one file has appeared.

Now run the magic move/rename command

bzr move --auto

You get output like this:

myproj/src/MyTest.cs => myproj/src/MyRenamedTest.cs

BZR has worked out (by looking at the contents of the file) that the missing file is in fact the one that has appeared. It has automatically done the rename/move. Remember, it wasn’t just the file that was renamed – the class was renamed too. The files are not identical, but it still worked it out.
If it cannot work it out, you can replace the “auto” option with the actual old and new file paths.

Rename and move a file to a new namespace/folder

Now let’s try something a bit more complex. Create a folder that will host the test classes and add it:

bzr add myproj/src/Tests

Now in dev studio, rename MyRenamedTest.cs back to MyTest.cs, and cut and paste it into the new Tests folder.

Now run the move/rename command again:

bzr move --auto

You get output like this:

myproj/src/MyRenamedTest.cs => myproj/src/Tests/MyTest.cs

Again, BZR has successfully worked out that you’ve renamed and moved a class.

Rename a namespace/folder that already has some files in it

Now, let’s rename folder myproj/src/Tests (which contains MyTest.cs) to myproj/src/UnitTests and check the Bazaar status. Running command:

bzr status

Gives you get output like this:

removed:
  myproj/src/Tests
  myproj/src/Tests/MyTest.cs
unknown:
  myproj/src/UnitTests/

So, right now, Bazaar thinks you have deleted the Tests folder and its contents, and added a new UnitTests folder.

Let’s fix this by first adding the new UnitTest folder.

bzr add myproj/src/UnitTests --no-recurse

giving:

adding myproj/src/UnitTests

Notice the very important no-recurse option. If we had left this option out, Bazaar would have added the folder and the files inside that folder – i.e. it would have added MyTest.cs as a new file, defeating the objective of telling Bazaar about the namespace rename.

Now that we have added the renamed folder, we can run the Bazaar rename command:

bzr move --auto

You get output like this:

myproj/src/Tests/MyTest.cs => myproj/src/UnitTests/MyTest.cs

Bazaar has successfully moved the file from the Tests folder/namespace to the UnitTests folder/namespace.