Best practice for dealing with branch sets in SVN

Navigation
1

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

Ex: We are currently working on TRUNK.12 which was generated from the release of TAG11, and from it we have 3 BRANCHS which are the 3 demands that will be developed. Once the branchs have been finalized they are merged into TRUNK and tested by HOMOL, but some of these branch requests are not approved and / or canceled, and come back to us.

We ended up getting a Trunk with all 3 branches and should take 1 or more of them.

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

P.s. Sorry if it was not so clear, it was the best way I could explain without adding more specific company data.

    
asked by anonymous 08.10.2015 / 22:19

2 answers

2

This is one of the reasons why SVN was being abandoned at the expense of using GIT.

As SVN is a CENTRAL repository and everyone uses only local referrals to track changes in teaming becomes complex.

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

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

  • Understand that there should only be one MERGES in TRUNK
  • What should be homologated is not TRUNK but rather the BRANCH with the subject.
  • Each developer MUST have a private BRANCH and in the end everyone MERGE the BRANCH of the SUBJECT and not the TRUNK, only at the end of the homologation is that the merge in TRUNK and generate a new tag.

Remember, there is not the correct versioning path, but the best practices that work in a particular case.

Here are some recommendations tips: link

    
09.10.2015 / 00:49
1

As you have the 3 demands that were made from TAG12, then we have that they are separated each one in 1 new branch, as the Merge for the Trunk was probably made that TortoiseSVN do not let make on account of being a Merge, at least TortoiseHG does not.

You have 2 options:

  • With commits of 2 requests that were not approved, revert commit to commit. Update Trunk, then roll back each commit of the 2 unapproved branches.

  • Create a new Trunk branch before Merge of the 3 demands with an acquired name, then merge the approved demand and continue, once the other 2 are approved merge into that branch that has already been Approved, then this new branch which you created from the trunk to stabilize, merge back to the trunk.

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

    Use the Vincent Driessen model:

      

    A successful Git branching model
    In this post I present the development model that I have 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 will not 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 do not know if you apply some agile methodology, but only merge Demands to the trunk, or the model I suggested, when approved by the approval, client, project manager, product owner, etc. That is, only put to homologate the version if the "Aceite" is given.

        
    08.10.2015 / 23:13
    Would it be possible to convert a form to pdf? How to add x icon in check box