CODEWITHSUNDEEP
svntagsdependenciesbranch
Samuel
Samuel

Reputation: 12341

Best "working practices" with svn when release versions

I'm in the process of implementing better "working practices" with svn at my job. We already used svn since a couple of years but we just use it I think at 20% of it's capacity; we use it for source code versioning but we don't use tags or branches concepts.

For the future, we want to be able to keep a snapshot of our applications code with the help of tags after each revision or release. Here is the article that helps me finding an orientation for the best strategy. This one also gives me some understanding but leaving me with more questions.

This is the pattern that I want to follow:

The problem is that we also have an homemade framework that applications depends on. The help of tags in our context is to be able to correct a small bug in an existing release without sending the newest version to the client; the version in the trunk. As you can imagine, the framework is not in the same groups of folders that the application and for this reason, I think it would be very sad having to create tags of the framework code linked with the release of the application. Consider that the framework itself can also changes without application specific requirements.

For this reason, I don't know which is the best strategy to create tags and diminish the pain if a bug in the framework was found in a previous release of an application. Currently, the applications refers to framework with libraries of the framework located in a libs folder of each application solution. What would you do in this case? Oh, I must indicate that the framework have 400 000 lines of code. The solution to copy and past will be rejected. :)

If I must fix a bug located in a previous version, how can I work with tags? I know that Subversion will notify me each time I will want to check-in in a tag structure. Must I create a branch with the tags, correct the bug and then merge/check-in the modifications back to the tags folder even if Subversion notify me?

I also have dependencies in my application like DataDynamics.ActiveReports and Mindscape.LightSpeed that are also dependencies in Visual Studio because these application are integrated in the IDE. How can I handle the case if I must correct a bug in a previous version that use a previous version of these IDE plugins?

Finally, It would be very appreciated if you could send me books or articles that could help me having a more deeply explanations for all these questions.

Thank you very much for you time.

Upvotes: 0

Views: 187

Answers (1)

JB Nizet
JB Nizet

Reputation: 691715

Well, the framework is a software product, and the clients of the framework are the applications using it. So the framework should follow the same rules than the application itself.

So here's the scenario. You released version A3.0 of your application. This version uses the version F2.4 of the framework. The SVN repository of the framework has a tag for the F2.4 release. The SVN repository has a tag for the A3.0 release.

A client of your application discovers a bug in the release A3.0. You create a new branch named A3.0.1, where you'll fix the bug. The framewok has noting to do with this bug. So you fix the code of the application in this branch, merge the fix to the trunk it applicable, and when ready, you make the release and create a tag named A3.0.1. In the branch and in the tag, you're still using the release F2.4 of the framework.

The client discovers another bug in A3.0.1. So you create a new branch named A3.0.2 to fix this bug. After investigation, you realize this comes for the framework. So you ask the framework team to fix this bug, and provide you a version F2.4.1. In the framework team, they create a branch F2.4.1 to fix the bug. Once ready, they release F2.4.1 and create a tag for this release. You include F2.4.1 in your branch A3.0.2, you make sure the bug is fixed (maybe you also need to make some changes in the application code), and when ready, you release the version A3.0.2 and create a tag for it. Your version A3.0.2 now depends on the framework F2.4.1.

Regarding the VS plugins, if they're not backward compatible, I don't see any other solution than keeping older versions. But I would not rely on an IDE, and even less on specific plugins of an IDE, to create and build software. IDEs should be interchangeable, and at the very least, there should be an IDE-independant way of building the software.

Upvotes: 1

Related Questions