RE: SVN branching strategy & tortoiseSVN

> We have a project team of roughly 10 people and we adopted this strategy:
> 1) Each developer has a nranch that he has read/write access to.
> 2) Before starting on a new fix/feature, he's required to make a copy of
> the
> trunk to a sub nranch within his own branch.
> 3) he proceeds to checkout from this sub nranch and work on it. When he
> commits, he commits back to the sub nranch.
> 4) When he's done, he freezes the changes to the sub nranch and informs
> the
> project manager.
> 5) once a week, the project manager makes a copy of the trunk to his own
> sub
> nranch, merges those developer's sub branches that have completed
> fixes/features and releases it for tester's validation.
> 6) when the testers validated the changes, the project manager will then
> proceed to merge those sub branches to the trunk and informs the rest of
> the
> developers to update their sub nranches with the updated trunk codes.

That is really complicated and seems like a lot of work.

> the repo structure looks something like this:
>
> <root>
> <developers> //developer branch
> <John>
> <Copied20100315> //sub branch copy of trunk
> <Copied20100316>
> <Daniel>
> <Copied20100215>
> <Copied20100301>
> .....
> <Tags>
> <trunk>
>
> We're using TortoiseSVN client. When making trunk copy, we're using
> TortoiseSVN's "Copy to..." by right clicking on the trunk in Repo browser
> and specfying the destination URL as a new sub branch.

That's fine.

> when merging back to trunk or merging trunk changes to our sub branch,
> we're
> using TortoiseSVN's Merge/Reintegrate branch. is this correct? or should I
> use "Merge a range of revisions"?

The answer is, it depends. Reintegrate is only going to work properly if you have merged in upstream changes. It is also designed to merge from a branch back to its source (where it was copied from).

It sounds like some of your merges might be cyclic which svn has a hard time with.

> Now some developers are requesting for inter branch merging, say in the
> example above, Daniel working on his sub branch "Copied20100301" needs
> some

This is certainly possible.

> changes from John's sub branch "Copied20100315", does Daniel use
> "Reintegrate branch" or "Merge a range of revisions"? say when daniel and
> John both merges their codes back to the trunk, will it cause conflict
> since
> daniel has John's codes that are not commited back to the trunk yet.

Once again, to use re-integrate or not depends on if you are keeping the branch up to date by merging from the upstream source.

> Could someone pls advice me whether the above usage scenario is correct
> and
> how to improve it? is there a site with more strategies on SVN usage so I
> can improve this strategy? thank you so much for your kind patience to my
> long post. Have a very great day ahead. Smile

First, the best advice I can give you is to read the Merging/Branching chapter in the svn book. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html espessially the Advanced Merging section.

To tell you the truth, something like Git or Mercurial is better suited to what you are doing. Since each dev has his own repository and he can pull/push changes to/from any other repository. However, assmuing you are not able or willing to change version control systems.

I would say rather than giving each dev a branch you branch for feature. This could be worked on by one or more devs at a time. this would most likely save the need for one dev to need something from another devs branch.

I would also use trunk as the workspace for the project manager. The devs could inform him that a feature is ready for him. Here I think you have two choices. The project manger can view/test the feature on the feature branch and once he is satisfied he can --reintegrate that branch to trunk and delete the branch. Or, he chould re-integrate into trunk and test there. Then, if all was ok he could merge that to a stable branch which is what QA tests.

BOb

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2573175

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-04-12 16:13:27 CEST