Best practice for handling branchsets in SVN

Asked

Viewed 847 times

1

Here in the company we use SVN for versioning. We have TRUNK that is available for approval before going into production and generating a TAG, and we also have BRANCHS that symbolize each demand. Until some time ago, each finished BRANCH (demand) was simply merged into TRUNK and made available for testing and homologation, but with the change of some management the concept of "packages" was inserted, that is, the demands would only go up to test/homologation in a set of demands/branchs (packages). At first everything was perfect, but with the ideas of the packages after a while began to generate problems.

Ex: We are currently working on TRUNK.12 that was generated from the release of TAG11, and from it we have 3 BRANCHS that are the 3 demands that will be developed. After the branchs have been finalized they are "mergeds" in TRUNK and tested by HOMOL, but sometimes some of these demands (branchs) are not approved and/or canceled, and come back to us.

We ended up with a Trunk with the 3 branchs and we should take 1 or more of them.

What is the best way to deal with this problem? Revert Trunk again to release 11 TAG? This is the best option?

p.s. Sorry if it wasn’t so clear, it was the best way I could explain without adding more company-specific data.

svn tortoisesvn tags branch trunk

2 answers

2


This is one of the reasons why SVN has been abandoned at the expense of using GIT.

As SVN is a CENTRAL repository and all use only local references control team changes will become complex.

On your question, to the point of generating a branch 12 from TAG 11 is OK.

My experiences with the SVN for cases similar to yours led me to follow the following rules:

  • Understand that there should be only one responsible for MERGES in the TRUNK
  • What is to be approved is not the TRUNK and yes the BRANCH with the subject.
  • Each developer MUST have a particular BRANCH and at the end all must MERGE into the BRANCH SUBJECT and not in TRUNK, only at the end of type approval shall the TRUNK merge and generate a new TAG.

Remember, there is no right way to versioning, but best practices that work in a given case.

Here are some recommendations: https://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

  • The only problem in this case is that TRUNK necessarily needs to go for homologation, for some unknown reason that no one could explain to me properly is in TRUNK that is made the validations of SONAR, tests and etc... :(

  • Very good this, pure class and type canonical answer to the question "which the best Xyz to do abc": Lembre-se, não existe o caminho correto para o versionamento e sim as melhores práticas que funcionem em um determinado caso.

  • @Brasofilo, I did not understand his comment and in what it helps to arrive at the solution. With versioning there is no CORRECT. If by chance you took the trouble to read the good practice page have some very interesting phrases like This is a hotly debated Question, and it really depends on the Culture of your software project. or There are Many Ways to lay out your Repository. The answer mentions a way to work versioning using GIT and not SVN. I worked years with SVN and MERGE has always been a birth, which is not the case with GIT.

  • I was praising this passage that I think is fundamental when it comes to "best practices". You can flag it as "nonconstructive" and a delete moderator without problems...

1

As you have the 3 demands that were made from TAG12, so we have that they are separated each in 1 new branch, as already made the Merge to the Trunk probable that Tortoisesvn do not let do on account of being a Merge, at least Tortoisehg does not let.

You have 2 options:

  1. With the 2-demand commits that weren’t approved, revert commit to commit. Update Trunk, then reverse each commit of the 2 unapproved branchs.

  2. Create a new trunk branch before Merging the 3 demands with an appropriate name, then merge the approved demand and continue, once the other 2 are approved merge into that branch that has already been Homologated, then this new branch that you created from the trunk to stabilize, merge back into the trunk.

Possible solution to not happen anymore (there is no correct way):

Use the model of Vincent Driessen:

The Successful Git branching model
In this post I present the Development model that I’ve introduced for all of my Projects (Both at work and private) about a year ago, and which has turned out to be very Successful. [...] I won’t talk about any of the Projects' Details, merely about the branching Strategy and release management. It focuses Around Git as the tool for the versioning of all of our source code.

I don’t know if you apply any agil methodology, but you only merge Demands into the trunk, or into the model I suggested, when approved by approval, client, project manager, product Owner, etc. That is, only put to approve the version if given the "Accepted".

  • As I commented there in the other answer, for unknown reason what goes to homolagation to have the "accepted" has to be necessarily the TRUNK that goes through SONAR and other validations. After all the right already generates the tag with the release version

Browser other questions tagged svn tortoisesvn tags branch trunk

You are not signed in. Login or sign up in order to post.