0
votes

I took a couple of SVN tutorials on how using branches/merge to work in team but something is still not working in the flow. I am using Tortoise SVN + Visual SVN Server in LAN. There are N developers.

Scenario 1: branch is inside main trunk

  • Developer-A checks out the "OurProject" production release, let's say from http://svn-server/OurProject. In the beginining there are no branches.
  • Developer-A creates "Branch-A" under the main path, so http://svn-server/OurProject/Branch-A. He switches the working folder to the branch and starts coding. He adds some files and edit some others. He commits the changes to the branch.
  • Developer-B knows nothing about his colleague's work and his branch, so he simply checks out the entire "OurProject" from http://svn-server/OurProject. This leads to Developer-B checking out the whole "OurProject" structure, with the "Branch-A" folder either! This is the first strange thing to me.
  • Developer-B starts a new "Branch-B" branch at the path http://svn-server/OurProject/Branch-B and starts coding.
  • Developer-B finishes coding, while developer A is still working. He merges his Branch-B into the project root and commits. This leads to "Branch-A" being deleted from the trunk by developer B! No, I don't think this is the right solution.

Scenario 2: branch is outside main trunk (merge from branch to trunk)

  • Developer-A checks out the "OurProject" production release, let's say from http://svn-server/OurProject/trunk. In the beginining there are no branches.
  • Developer-A creates "Branch-A" under the "branches" subfolder, so http://svn-server/OurProject/branches/Branch-A. He switches the working folder to the branch and starts coding. He adds some files and edit some others. He commits the changes to the branch.
  • Developer-B knows nothing about his colleague's work and his branch, so he simply checks out the entire "OurProject" from http://svn-server/OurProject/trunk. This leads to Developer-B checking out only the production code, without visibility of the collagues' branches. Fine.
  • Developer-B starts a new "Branch-B" branch at the path http://svn-server/OurProject/branches/Branch-B and starts coding.
  • Developer-B finishes coding, while developer A is still working. He merges his Branch-B into the project root (from branch to trunk) and commits. This leads to trunk overwriting all "Branch-B" modifications! Not right.

Scenario 3: branch is outside main trunk (merge from trunk to branch)

... (same as previous scenario, except last point)

  • Developer-B finishes coding, while developer A is still working. He merges his Branch-B into the project root (from trunk to branch) and commits. This leads to Tortoise SVN warning for conflicts. I choose "Mark as resolved, accept current working copy state".
  • Developer-B switches to trunk and SVN deletes my new branch files and again all my branches modifications are lost.

After dozens of tries I wonder which can be a real flow. Thank you for any help

2

2 Answers

0
votes
  1. Don't use SVN in 2020, it have sense only for really old big projects with long history and lazy devops (and some other rare cases outside your scope). "Merge Hell" is Real Pain in Subversion, unavoidable
  2. If you still stop on SVN:
  • read SVN Book
  • select preferred repo-tree
  • define, declare and follow Development Policy (TBD, BranchPerTask, etc) and Access Rules

After all you'll get all answers for all 3 use-cases. 1 is just ugly useless style, 2-3: SVN delete nothing, read about moving in history in SVN, selecting tree, etc

0
votes

It appears that your project's layout is invalid. Did you create /trunk in your project's root?

Please, read SVNBook:

Scenario 1: branch is inside main trunk

You don't need to store branches inside trunk or inside other branches. The project layout you are describing in this scenario is incorrect and will definitely cause you headache in future. Moreover, with this layout you will - by default - checkout all the branches when you want to checkout the trunk only.

It appears that you assume that /OurProject is a trunk of your project, but it is not and should not be. If you prefer to use the common "trunk, branches, tags" layout, then your project's root directory should include these directories:

branches/ https://svn.example.com/MyRepo/MyProject/branches
tags/     https://svn.example.com/MyRepo/MyProject/tags
trunk/    https://svn.example.com/MyRepo/MyProject/trunk

Scenario 2: branch is outside main trunk (merge from branch to trunk)

...

Developer-B finishes coding, while developer A is still working. He merges his Branch-B into the project root (from branch to trunk) and commits. This leads to trunk overwriting all "Branch-B" modifications! Not right.

Normally, the trunk != your project's root. If you merge changes from /branches/MyBranch to /trunk, the changes from your branch will appear in trunk once committed. I.e., you are reintegrating the branch changes back to trunk.

The same applies to your Scenario 3. But if you are "merging a Branch-B into the project root (from trunk to branch)", you are syncing your branch with changes made to trunk since you created this branch. I.e., you are keeping the branch in sync with trunk.