We help IT Professionals succeed at work.

SVN: Keeping a Reintegrated Branch Alive

I am new to SVN and am using VisualSVN with Visual Studio.

While reading the SVN Book, I was surprised when I read this:

Once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again. For this reason, if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk

After further reading, I understand the technical reason behind this statement, and it makes sense.  But I'm wondering whether this would be a hassle if you had to revisit a  branch to fix a bug.

Here is a scenario that I have had:  Branch V1 is deployed to production and working well, so I merge it into trunk.  I then create a new branch V2, and start development of new features and code changes to the app.

I then learn about a bug in V1 that was identified in production.  I want to "switch" to the V1 branch fix the bug, and prepare a new V1 release for production.

I then switch batch to V2 and resume coding.  The next day, I am informed about some other issue in production that needs to be fixed ASAP.  I want to switch back to V1 again, fix the issue, and prepare a new V1 release.  Then switch back to V2.

Eventually, I would merge the additional V1 changes into trunk or into the V2 branch--I haven't tested that yet, so I'm not sure of the best approach.

But in this scenario, if I use --reintegrate when originally merging the V1 branch into the to trunk (and then deleting the V1 branch), my understanding is that I would need to resurrect V1 to make fixes.   This seems like a bit of a hassle, and introduces additional steps that could introduce human error (e.g. if I chose the wrong revision when resurrecting).

So I then saw the SVN Book section on "Keeping a Reintegrated Branch Alive".  This seems appealing in my scenario, as it would appear to allow me to safely persist my V1 branch.

So is there any downside of Keeping a Reintegrated Branch Alive?  It seems like keeping it alive would be more convenient, and I can't think of any obvious downsides.

Does anyone keep a reintegrated branch alive?  Or do you always delete merged branches and then resurrect only when necessary?
Watch Question

You may not like to hear that, but you should switch to Git. I have jumped to Git from CVS, thinking also about SVN for a while (few years ago). SVN is a bit better than CSV. Anyway, I know how do you feel with branches.

I feel lucky now that I have chosen Git. My guess is that there is a lot of people who found Git or Mercurial or Bitkeeper or any similar system much better and easier to use than the CSV-family tools. I could bet that there is no person that knows Git and Subversion (at about the same level) who would voluntarily chose Subversion.

The good thing for you all is, that there is a SVN to Git bridge.

Installation of Git is very easy, free literature is excellent. Visual Studio now supports Git out of the box. Anyway, I prefer the Git tools that come with the official installation.


Thanks for the info on Git.  The SVN Book mentions Git, and explains that it uses a very different client-centric distributed architecture, vs. the centralized SVN repository architecture.

I haven't invested a whole lot into Visual SVN, so I'm open to changing if there is a very compelling reason.  It did take me many hours to learn the quirks of Visual SVN and its integration with Visual Studio, but I'm open to switching if there is a clear benefit.

Does Git handle branching and branch management in a way that eliminates the issues / concerns I have with SVN?

Can you offer a brief explanation of how you would handle the trunk / V1 / V2 situation I described using Git?

And for context, I'm an independent developer, so I'm the only one modifying and maintaining code.  So my needs are relatively simple--but I do want to be able to manage branches as I described.
I will summarize what I remember about CVSNT (more modern than CVS, closer to SVN). Branch is a strong abstraction. The system keeps changes along the branch. It is not that difficult to create a branch (even though it may be time consuming). Merging is rather not elementary thing. Merging twice may sometimes be surprising/dangerous. It is not that easy to extract certain version of sources. Central repository seems to be natural and easier at first look.

In Git, the commit point is a central abctraction (my explanation). It is uniquely identified by the content of the sources. Having access to a commit point, you have all the sources of the project that were captured at the time.

If you know basics of the graph theory, then commit points are nodes, and oriented edges point to the direct predecessors. Acyclic graph is formed that way. Branch is only a pointer to one of the commit point. To make a branch means to copy one pointer (20 bytes).

Merging in Git is based on analysis of the merged points and of their predecessors. Branch "pointers" just say what points will be merged. It is even possible to merge more than two branches at once easily. It is possible even to choose the merging algorithm, but I have never needed it.

The commit point can be tagged. The tag also points to the commit point. It means that you can easily and fast create a branch at the tagged commit point -- or even for any untagged commit point.

I am sure Git fits well with your development scenario.

The official distribution http://git-scm.com/ for windows is fine.

Use "git gui" and "gitk" commands.


Thanks for the info.  Sounds like I'm going to have to do some reading about Git to get up to speed and understand its design and commands.  It does seem like it has become more popular than SVN due to its design, features, and support for local repositories and distributed online/offline development.

I checked with two corporate developers I know and they both now use Git (one previously used SVN).  One uses Github and the other uses Bitbucket.  Since I want private repositories, I'm going to try Bitbucket first, since they offer 5 private for free.

The hosted repositories is an added benefit, since I'm currently hosting my own VisualSVN Server.  It has been zero maintenance, but it's just one more VM that I would be happy to get rid of.

Thanks for recommending Git.  I'm going to try it this afternoon.


Thanks for the advice to consider a new solution rather than try and figure out the SVN workaround!


Thanks!  I already downloaded the book as a PDF and sent a copy to my Kindle!

I have several hours of reading and testing in my future...

I read that Visual Studio 2013 has native support for Git and Git repositories, so I'll have to look into that and see if it is sufficient, or if I will need to rely on a separate windows client app / command line tools.
You may also be interested in Visual Studio 2015 Community Edition for your personal usage. It is one step better than 2013, free of charge when legal conditions are fulfilled, and implements the features of the Professional edition (i.e. better than the Express edition).

GIt is also a kind of framework/underlying infrastructure -- tools built around the repository. The repository does not care what tool was used to manipulate it. This way, you can combine built-in features of Visual Studio with out-of-the-box Git tools, third party tools, whatever. You can think about GitHub as about one of such toolsets combined with the remote repository.

In Visual Studio, you can see a small icon near the filename in the project that indicates when the file was changed and not commited.

I also recommend to read the Git GUI Tutorial http://nathanj.github.io/gitguide/tour.html It is a bit dated but still valid. It may look old-fashioned, but it is good. For the most usual tasks, I use "git gui" instead of the command line commands. Actually, it is the first time when I prefer to use GUI for a revision control system. It does not introduce some "clever ideas" to hide some underlying principles. You will be able to understand it better when you learn what the Git is.


Thanks.  I have an MSDN Subscription, so I have access to VS 2015, but the Microsoft ERP system I work with only supports up to VS 2013 at this time.

I read most of the Pro Git book last night.  A bit overwhelming.  Not nearly as easy to read and understand as the SVN Book.  While I understand the concepts they presented, it does look like I have a larger learning curve ahead of me.  It seems like it might be harder to visualize the state of a Git project at any given time, whereas SVN is simpler due to its design.  Still learning though, so I'll have to get used to it--obviously lots of people use it, so it's me, not Git.

One last question.  On GitHub and Bitbucket, they seem to equate a Repository with a single code project.  Is that correct?

For instance, if I develop App 1 and App 2, do I need to private repositories for those two apps?  Or can I somehow have one repository (Acme Co) with two folders for App1 and App2?  With SVN, I had a single repository with folders for clients and subfolders for projects (VS Solutions), so I'd like to maintain that if possible--but I don't know if Git has different recommended practices for that.
For the visualisation, try the mentioned gitk.

You can choose whatever directory structure. It is a design decision. However, you probably do not want to put together technically unrelated things.

I forgot details o CVSNT already. But I remember I tried hard to simulate CVS branches on Git. Actually, there is no need for that. You only have to get used to rather simpler approach.

What you *really* need from any RCS is to keep the history somehow, to mark/tag certain points in time, and you want to be able to get the full snapshot of files for certain time point. Also, having two  , you want to be able to merge reliably. There are also other important things, but you need the cote functionality that is easily used.

You have to try some scenarios on your own. It is very easy to experiment with Git also using gitk.


Quick update...

I have now transitioned to Git and Bitbucket with Visual Studio 2013.  It has been great so far.  I've created several branches on a larger project to push bug fixes in production while developing, without interruption, on a separate "new features" branch.

I have transitioned several other VS 2013 projects from VisualSVN to Git / Bitbucket without issue--the process is relatively simple, although I do still have to refer to my notes every time, as the various clicks withing Visual Studio are not obvious.

Visual Studio 2013 has native Team Explorer Git support, so it works seamlessly. VS 2012 requires an install of the Git component, but is apparently as seamless as VS 2013.  VS 2010 isn't nearly as simple, as it requires manual install of several components plus additional configuration.  But it does work.

I went with Git hosting through Bitbucket so that I could eventually move away from hosting my own source control server.  I chose Bitbucket (instead of Github) because all of my repos are private; GitHub charges for every private repo, whereas Bitbucket charges by user and offers unlimited private repos.

I use SourceTree (available free with Bitbucket) for pretty pictures.

Git branch graph
Visual Studio Team Explorer doesn't support all Git features (like stashing), but you can use the "Package Manager Console" in VS to issue git commands.

Overall, it's worked out very well and I'm very happy with Git.
Nice to hear that :)

I would like to add only one small suggestion that is actually related only to one of the ways/purpose to use Git, not to the Git itself. You can make your flash stick a handy media for having your repository always with you. The only thing you need at the other computer is the Git installed. Here is how I do it (using command line here):

plug in the flash stick
create the directory there -- say MyProject.git (the .git extension of the repository is by convention to express that it is a bare repository)
launch the cmd, and cd to the above mentioned directory (say, you are at e:\__repo\MyProject.git)
type git init --bare
go to your MyProject repository that you already have on your hard disk (that is launch cmd, and cd to the repository)
type git remote add flash e:/__repo/MyProject.git

Now you can whenever push to the flash disk, pull from the flash disk (equal to fetch + merge), clone it to whatever other hard disk, and so on. And you can always be sure you did not forget to copy some of the files. Still, only the newer files are copied.

On the other hard disk, the clone know the flash disk as origin. To make it clear that you will use the flash disk, use  git remote rename origin flash. Then the remote repository will be renamed to flash for your local computer.

Notice, that the drive letter may be different on both computers. The drive letter is remembered during the remote add or clone.


Hmmm, interesting, thanks.  So the value is to have a mobile copy of your repositories?

All of my development is done on VMs, so I don't have any dev tools or code on my workstation or laptop.  Since I rarely travel, and pretty much always have Internet access, this has worked out okay--I just RDP into my VMs to code.

Another benefit of this approach is that it lets me access everything consistently from all devices.  I can get to my servers from my iPhone, iPad, or laptop all through OpenVPN and RDP.  Editing code on a phone or tablet is tedious, to say the least, but it works in a pinch, and with a Bluetooth keyboard, the iPad is actually tolerable.

The transition to Bitbucket should provide more flexibility for accessing my code, but just in case, I've also setup Bitbucket Backup, which runs nightly to pull all of my repos down to a VM.  


I haven't yet tried to use or 'restore' the backup files, so that is next on my list.

Ideally I'd like to transition my Windows VMs to  Azure, but at current prices that would be very expensive, so hosting them internally works for now.

I recently did a pull + merge of numerous master branch changes into a new features branch (don't know the proper name for that), and it was amazingly smooth.  The handful of conflicts and hundreds of changes were very easy to review and merge.  The merge / comparison interface, at least in Visual Studio, seems much easier to use than what I had with TortoiseSVN / VisualSVN.

One interesting Git feature I haven't tried yet is stashing.  The Visual Studio 2013 integration doesn't support stashing, so it has to be done via console / command line.  In my case, doing a commit before switching branches isn't a huge deal, but I'm curious to try stashing.

I'm still reading through the Git book, so there are likely a few other features I need to learn about and try.

Thanks for the suggestion to look at Git--it has really changed my perspective on source code control and brought me up to speed with current tools.