2009/6/3 Bob Archer <Bob.Archer_at_amsi.com>
> >>> That's the way im working now.
> >>>Work on trunk. When im ready to release, branch. If i have bug fixes, i
> correct them in branch, >>>and then i merge them to trunk.
>
> >>You might want to consider the method svn team uses. They don’t check
> into release branches. They would >>make the fix on trunk and then merge it
> to the release branch in order to build/test. I want to move to this
> >>work-flow soon too.
>
>
> >yes, but i dont know how to merge to the release branch only the bugfixes,
> and ignore the new >things that apply only to the trunk, if for example i
> have in the same file both type of changes.
>
> You specify the revision that you want to merge. It is called
> “Cherrypicking” in the svn book.
>
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.cherrypicking
>
> BOb
>
It sounds great, but that requires that the commit would only include
bugfixes and nothing related to the new version. And as i know thats the way
it should work, it took a lot of time to educated the team to use svn, and a
lot more time it would require to say them that they never had to mix in a
same commit bugfixes to previous versions and new features.
Both strategies had pros & cons, so i guess that it depends on the team and
the project.
Thanks!
gonzalo
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359182
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-03 20:39:32 CEST