Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Subversion Feature Branch Best Practices

No description

Quincy Bowers

on 21 October 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Subversion Feature Branch Best Practices

Subversion Feature Branching
Best Practices
First I'll convince you that feature branches are the best thing ever
Then I'll show you how to use them the right way
The case for a stable trunk
Your team should value keeping trunk stable at all times
An unstable trunk can hide issues, you may fix one problem only to find another one
Fixing a critical bug on an unstable trunk is dangerous
Stability means trunk always passes all tests and could probably be released from at any time
Stability means confidence
You're already branching whether you realize it or not
Your working copy is a branch
But it's a branch without the safety net that merges provide
Ever get a conflict from
svn update
Do you happen to know a good way to undo that update?
Benefits of feature branches
Isolation from trunk
You control when work from other devs shows up on your branch
Your branch could (should) have its own build job on devbuild
Your branch could (should) be running its own automated tests
Your branch can be deployed with Version Manager
Changing your mind becomes easier, experiment safely
Context switching between cases is easier
You can push your changes to the repository more often, protecting you against a hardware failure
Things to never do with branches
Never merge into any folder except for the project root
Doing so will cause Subversion to write metadata called svn:mergeinfo in all sorts of inappropriate places
This metadata will then have to be maintained going forward
As a result merges will take longer and longer as Subversion has that much more work to do
Subtree merges can also result in partial commits being applied
Begin a merge without an update
Never start merging without first running
svn update
or checking out a fresh working copy
You'll just end up with a conflicted working copy when you inevitably have to update when your merge commit fails
Merge into a subfolder of your project
Merge into a dirty working copy
Never merge into a working copy that has local modifications
svn status
shows anything at all then you need to delete the changes or commit them before attempting to merge
Things to always do with branches
Merge from trunk often
Merge from trunk several times a day
That keeps each merge very small which reduces the chances of conflict
When conflicts do occur, they are probably only from one or two commits and the conflicts are small because everyone is only checking in small commits, right?
Keep trunk stable or you will propagate that instability to your branch!
Keep your commits small
The smaller your commits, the less chance for conflict
Break your changes into small, logically-related commits
Keep formatting changes in a separate commit from
Make your log message useful
But when cherry picking a commit from trunk over to a release branch, you need to be much more specific
Subversion doesn't do a great job of telling you which commits are included in a merge
You have a responsibility, therefore, to provide that information in your commit message
r800206 | qbowers | 2016-10-12 10:31:01 -0600 (Wed, 12 Oct 2016) | 8 lines

Merged r800137 from trunk.


Ensuring the stop service command succeeds on Windows if the service was
already stopped.
Make your log message useful
When doing a full merge from trunk into your branch it's sufficient to just say that
r800206 | qbowers | 2016-10-12 10:31:01 -0600 (Wed, 12 Oct 2016) | 8 lines

Full merge from trunk.
Merges from trunk should be full merges
Let Subversion calculate the revision range from the svn:mergeinfo for you
If you are specifying a revision range for your merge from trunk...don't
Don't add stuff to the merge
After your merge command, don't be tempted to make any changes apart from the bare minimum to resolve conflicts
Useful stuff to learn how to use
svn:merginfo property
svn mergeinfo
svn log
Feature Branch Workflow
Right now we're on trunk
Let's branch from this commit
Looks like trunk has had a few commits
Now we can start working on our branch
And a second commit, good. Now let's merge from trunk so we don't get too far behind.
Let's merge them in
This is a full merge from trunk, so we don't need to specify any revision numbers

Subversion will calculate that automatically from the svn:mergeinfo
$ svn status
# notice the clean working copy...
$ svn switch http://repo/project/branches/feature1

# Alternatively

$ svn checkout \
> http://repo/project/branches/feature1

# Or you can use sparse checkouts

$ # work work work
$ svn commit -m "Fixing the things."
$ svn update
$ # work work work
$ svn commit -m "Fixing the other things."
$ svn update
$ svn status
# Notice the clean working copy...
$ svn update
$ svn merge http://repo/project/trunk .
$ svn commit -m "Full merge from trunk."
$ svn update
One more commit ought to do it...
$ # work work work
$ svn commit -m "Fixing the last things."
$ svn update
Let's get ready to merge back to trunk
Looks like trunk has had a few more commits
We'll need to merge those into the branch before merging back to trunk
This is another full merge from trunk...
$ svn status
# Notice the clean working copy...
$ svn update
$ svn merge http://repo/project/trunk .
$ svn commit -m "Full merge from trunk."
$ svn update
Now we can merge back to trunk
This is a full merge from branches/feature1
Arguments against feature branches
They cause more merge conflicts
This is true...if you let your feature branches live for a long time, accumulating lots of changes without merging from trunk often.

But, if you make small focused changes and merge from trunk often, then you shouldn't see any more merge conflicts than if you work on trunk.

In fact, when you do have conflicts on a feature branch they are easier to deal with. All of your local changes are committed, as opposed to local modifications in the working copy that conflict when you update.

If you ever have a merge conflict while merging back to trunk that means that trunk has not been fully merged into your branch.
They make refactoring harder on the team
This is true...if you are doing all the things I told you not to do in the last bubble.

Break your work up into small logically connected chunks. Commit those separately, taking care to ensure the tests continue to pass.

I have never seen any case that couldn't be broken down into something that could conceivably be completed in less than a day.

Refactoring in small committable steps
be more work than one huge sprawling commit. But can you really argue that it's safer?
Why should you listen to me?
I've been using Subversion since ~2007
I have had to support other Subversion users for most of that time
The opinions you are about to hear are informed by my experiences
There are likely other ways to use Subversion without shooting yourself in the foot
This is just what has worked for me
$ svn copy -m "Creating feature branch for feature1." \
> http://repo/project/trunk \
> http://repo/project/branches/feature1
$ svn status
# Notice the clean working copy...
$ svn switch http://repo/project/trunk
$ svn merge http://repo/project/branches/feature1 .
$ svn commit -m "Merged branch feature1 back to trunk."
$ svn update
Merging from trunk all the time is just extra work
Question, what is the difference between merging from trunk and doing
svn update

Answer, there is no difference, conceptually. The merge does require the additional step of committing the changes. But both an update and a merge can cause merge conflicts.

The difference is that the merge lets you deal with the conflicts after your local changes have already been committed. If you run into problems you can revert the merge and try again.

An update creates conflicts with your uncommitted changes. That's scary.
Feature branches are the best thing ever
Let me show you why
Rename, move, and delete without touching base with your team
Feature branches can be a bad place to rename a package or move a file
It is likely to introduce a tree conflict
Try to communicate structural changes to your team before doing them
Make those changes, discretely, on trunk
Preferably when there are few feature branches in flight
$ tree project
+-- branches
| +-- feature1
| +-- sub-module1
| +-- sub-module2
+-- trunk
+-- sub-module1
+-- sub-module2
You're allowed to merge here
But not here
Full transcript