R – Should you use branches in subversion if only one person is working on a project

branchsvntrunk

I'm just starting out using Subversion on a C# project. I am working on this project alone, yet I'm trying to treat is as if I was working in a group for my own learning experience.

As I understand it the typical way of working with subversion is to have a trunk folder that will always build. Major changes are then create in new branches, which are then merged back into the trunk when they are complete. So there may be many simultaneous branches being worked on by different team members.

But if I'm working on my own is there any point to making a branch? Say I'm at revision 100 in HEAD. I'll create a branch at revision 101, and then keep working on the branch until Revision 110. Now I can merge 110 back into the trunk, but there is no one else on the project so there won't be any change in the trunk to merge back into. I'd just be merging right back into revision 100 where I original created the branch.

Best Answer

Branches have nothing to do with how many people are working on a project. A branch is for an alternate development stream, like different feature sets, hardware targets, or clients.

If 100 people are working on a single deliverable they should be using the same branch. If a single individual is supporting a dozen different deliverables he should have a dozen branches.

Now you want to commit onto the SVN server

[Eventually] stash the modifications you don't want to see committed on the SVN server (often you commented some code in the main file just because you want to accelerate the compilation and focus on a given feature)
```
(work)$> git stash
```
rebase the master branch with the SVN repository (to update from the SVN server)
```
(work)$> git checkout master
(master)$> git svn rebase
```

go back to the work branch and rebase with master

(master)$> git checkout work
(work)$> git rebase master

Ensure everything is fine using, for instance:

(work)$> git log --graph --oneline --decorate

Now it's time to merge all three commits from the "work" branch into "master" using this wonderful --no-ff option
```
(work)$> git checkout master
(master)$> git merge --no-ff work
```

You can notice the status of the logs:

(master)$> git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|\  
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/  
* 21e20fa (git-svn) last svn commit

Now you probably want to edit (amend) the last commit for your SVN dudes (otherwise they will only see a single commit with the message "Merge branch 'work'"
```
(master)$> git commit --amend
```
Finally commit on the SVN server
```
(master)$> git svn dcommit
```
Go back to work and eventually recover your stashed files:
```
(master)$> git checkout work
(work)$> git stash pop
```

Using TortoiseSVN how to merge changes from the trunk to a branch and vice versa

I couldn't properly follow the other answers, here's more of a dummies guide...

You can do this either way round to go trunk -> branch or branch -> trunk. I always first do trunk -> branch fix any conflicts there and then merge branch -> trunk.

Merge trunk into a branch / tag

Checkout the branch / tag
Right-click on the root of the branch | Tortoise SVN | Merge ...
Merge Type: Merge a range of revisions | Click 'Next'
Merge revision range: Select the URL of the trunk directory that you copied to the branch / tag. Enter the revisions to merge or leave the field empty to merge all revisions | click 'Next'
Merge options: I just left these as default | click 'Merge'
This will merge the revisions into the checked out branch / tag
Then commit the merged changes to the branch / tag

Best Answer

Related Solutions

Git – Is git-svn dcommit after merging in git dangerous

Now you want to commit onto the SVN server

Using TortoiseSVN how to merge changes from the trunk to a branch and vice versa

Merge trunk into a branch / tag

Related Topic