jason scott gessner wrote:
> Hello all.
> What we want to avoid is the common merge problem of changes being
> applied more than once. Our plan ATM, is to do branches for "release"
> or "feature", then merge into a branch for QA and release. The
> wrinkle we keep running into is how to pull in production bug fixes
> onto the development branches and figuring out where to do this.
>
> In a message from May, Ben Collins-Sussman wrote:
>
>>If anyone has any good advice on doing this type of process, I'd be
>>happy to hear about it.
>
>
> Here's some advice: merge in one direction, rather than two. Your
> 'production' branch is just like a software release branch. Many
> projects (including Subversion itself) have a rule that new changes
> -- whether they be features *or* bugfixes -- are only ever made on
> trunk, and then selectively ported to the release branch. It makes
> for much less headache.
>
> Does this mean that the SVN team runs many branches and decides that
> branches A, E, I, O & U will make it into the next release? This is
> something that we were thinking about, but not used to from our
> current CVS experience.
>
> Sooooooooooooooooooo (to the two of you with the patience to sit
> through this.....), my ultimate questions are this:
> 1) Are there examples of branching structures that are more
> complicated than what is in the svn book that I could look to for some
> inspiration?
> 2) Is a tool like svnmerge something reliable enough to help out with
> this situation?
> 3) Are there SVN features on the road map for upcoming releases to
> address these more complicated branching situations?
>
> Many thanks for your time and sorry for the rambling nature of this message.
>
The other option is to use SVK to manage your branches. As long as only
SVK does the actual merging, you can continue to use svn clients for
everything else if you so desire.
SVK does the merge tracking for you, so you can push and pull changes
between branches without having to remember revision numbers or worry
about the same changes being applied more than once.
--
Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 6 08:57:39 2005