Version control system -> branch question

Question

I am working on the next task and suddenly understand that I need to discuss some details with my chief in order to continue. I will discuss it in a couple of days when I meed my chief. Until then I need to work on another task.

What is the correct way to do?

I see 2 options:

1) Copy head revision from repository to a new branch and start another task there. After I finish it - merge it to the trunk. Or maybe I will need to merge from trunk to the branch first, and then merge back to the trunk?

2) Copy from working copy to a new branch. Revert trunk to the last revision (before I started the task I need to discuss), switch to the trunk and work on another task, then finish my current task in the branch and merge.

Please, explain correct way in details, as I am not an experienced VCS user. Thank you in advance.

Answer 1

The trouble your facing is that you started the changes on trunk but want to commit it somewhere else. Most version-control systems don't have a built in behavior for this, which is unfortunate. In SVN, your best bet is this:

1. Create a new branch off trunk
2. Do an SVN switch to switch your current working copy to that branch
3. You should now your local changes and be able to commit them on the new branch
4. After you commit them to the branch, do another switch back to trunk
5. Work on the new feature on trunk
6. After you discuss the details with your chief, merge them from the branch back to trunk

Hope that helps

Answer 2

We branch based on release not task. So right now everything we are getting ready to release in a few weeks is in branch 5.1.1. The changes are merged back to trunk when they are published to production.

Answer 3

Really both choices will work for you and neither is more correct than the other; what will determine the easiest course of action is the difficulty required to merge the changes. In general in svn you want to avoid merging, if possible.

Usually this kind of decision depends on your team culture; if your coworkers don't generally want unfinished/unapproved changes in the trunk then it makes sense to move your changes to the branch and then merge after your chief approves your code. Of course if you are working solo then it is all up to you.

You really have a third option that may or may not work depending on your situation, which is just to work on two tasks in the trunk at the same time, and commit the individual changes separately.

Answer 4

I will do the first option because I can keep my trunk clean (working at all time). Since the feature you are talking about still need to be confirmed by your boss. If the feature end up thrown away, you trunk will still be unaffected and other members in your team will not be confused with that changes.