Here is what i want to know.
We will develop a software and releases a major version v1.0 of it.
After moving that version into production if we find any bugs we will fix those and deliver a patch version p1.0.1 to be applied over the existing major versionv1.0 which consists only modified classes for the bug fix. And it continues like whenever any bug found or an enhancement has to be applied, we will release a new patch version to be applied over the existing major version and existing patches.
So, How can we maintain only modified source(java) files for particular patch release? Like we need to have complete source code and separately we have to maintain patch source on top of that. We have to sync this code in SVN as multiple people involve in bug fixing, and patching.
Trunk, Branches, Tags will it full-fill our needs?
Please suggest.
There are several standard ways of doing development. I like what's called the unstable trunk method.
In unstable trunk, you do all of your development on trunk. Everyone works together. We have over 100 developers and don't have issues with it. It forces developers to work together, make small changes, and constantly commit these changes.
It also works well with a continuous integration builder like Jenkins.
When you get to some magic point, you create a release branch. What is this magic point? It depends. The idea is that as you get close to a release, you will have some developers working on the up coming release and some developers working on features that will go into the very next release. Two groups working in parallel means branching.
In some groups, this is when you get to the point of a release candidate or when you are feature complete on a release, and now you're just fixing bugs. At that point, you create a branch for your release. Our standard is to call that branch after your release.
You have a team of 10 developers. You are working on Release 1.2. All work is currently on trunk. Now that the release is almost complete, you assign two of those developers to work with QA and UAT to fix up the code and work on the release. All other developers are continue their work.
You create a branch called 1.2 using svn cp to copy trunk to branches/1.2. Now, those two developers working with QA and UAT work on Branch 1.2 and the rest continue working on trunk.
Once you are ready to release the code, you can use svn cp to copy branches/1.2 to tags/1.2.
You now have some bugs that have been fixed on your 1.2 release that may apply to that 1.3 release you're working on in trunk. In that case, you can use svn merge -c $REV where $REV is the revision in Subversion where you fixed the pertinent bug. Notice there's no reintegration. You simply apply the patches in branches/1.2 to trunk.
You've released Release 1.2, and a critical bug was discovered. The customers can't wait for Release 1.3, so you'll fix the bug now and create a Release 1.2.1.
In this case, since you already have branches/1.2, you simply patch that branch, and then when you are ready to do your release, you copy the 1.2 branch to tags/1.2.1.
Once again, you merge individual changes from branches/1.2 to trunk via svn merge -c $REV.
NOTE: There's no need to create a 1.2.1 branch. However, there's not anything preventing you to do that if you so prefer. You could have copies
tags/1.2tobranches/1.2.1and do your work there. Then, you could copybranches/1.2.1totags/1.2.1when you do a release.The only possible issue is that your branching is from
trunk->branches/1.2->tags/1.2->branches/1.2.1. Merging/branches/1.2.1back intotrunkuse to cause problems in older versions of Subversion. This shouldn't realy be an issue in Subversion 1.6 or greater.
One more piece of advice: Do not reuse release names or tags. You can talk about release 1.2, but each patch should be tagged 1.2.1, 1.2.2, 1.2.3, etc. Or, 1.2p1, 1.2p2. The point is that you should be able to point to each and every release you've delivered to production. If you want to know what changed in patch #3, you can do a diff between 1.2.2 and 1.2.3.