RE: branching strategies in subversion

I suspect we've got a language barrier to get past. Sorry for the top post, on outlook here.

I think you want to do the following:

Each developer branches Trunk to a 'personal' branch and commits work to that branch. When a developer has code that's ready for release, he/she would then merge that branch to Trunk which you could then do a release from.

That could work however a lot depends on how many people are working on the same code or code areas. The other developers would likely need (or want) to merge changes that have been committed to trunk back into their branches so they can see the work of others and have complete code.

I would think though that you would want a release branch and one person responsible for merging trunk into the release branch so that any breakage in trunk doesn't get released.




From: trucken8_at_gmail.com [mailto:trucken8_at_gmail.com] On Behalf Of jes Struck
Sent: Monday, November 28, 2011 4:11 AM
To: users_at_subversion.apache.org
Subject: branching strategies in subversion


Hej

I started to investigate the branching strategies of subversion. to compare with Git, Mercurial and ClearCase.
These three tools have an opportunity to branch out in a developer branch from which to deliver the trunk several times, so that such branches may be seen as developers industry instead of features industry. In Subversion, it seems that the second time you try to deliver the subversion dispose of any changes you've ever made any page on this branch

[cid:~WRD000.jpg]

So that second time i deliver it tries to deliver changes from Both Changeset A and B

i would rather have it only took Changeset B?

is this me that does not now how the correct way is to due it?