2008/7/11 Jeff <jsbmsu_at_gmail.com>:
> So, acceptable/advisable approaches would be.........
>
> (Figure numbers refer to TortoiseSVN 1.5 Manual, and only to indicate
> which dialog, not the entered info depicted in those figures)
>
> Short-lived feature branch:
> - Create branch, resulting in Rev A
> - Make changes/commits to branch without merging in any trunk changes
> ever. Final change results in Rev. B.
> - Switch WC to trunk
> - Use "Merge revision range" dialog (Fig. 5.35) to merge FROM
> <URL_of_branch> with Revision range: A-B
> - Commit WC to trunk.
>
> Long-lived feature branch:
> - Create branch, resulting in Rev. A
> - Make changes/commits to branch
> - Keep synchronized with trunk using "Merge revision range" dialog
> (Fig. 5.35). How about a loop:
> --- 1. X = A
> --- 2. Merge FROM <URL_of_trunk> with Revision range: X-HEAD
> --- 3. Commit WC to branch. Y = resulting revision
> --- 4. Continue making changes/commits to branch, until ready to pull
> more trunk changes
> --- 5. X = Y (That is, Rev. of last sync with trunk)
> --- Repeat steps 2-5 until ready to merge branch back into trunk
> - Now, branch changes are done, and all trunk changes were *very*
> recently merged into the branch, resulting in Rev. Z (=Y_final)
> - Switch WC to trunk
> - Use "Tree merge" dialog (Fig. 5.37) to merge FROM trunk_at_Z TO
> branch_at_Z
> - Run Update on WC to get any possible last-minute changes from trunk
> since Rev. Z
You don't need to worry about a race conditions here. If you were
merging trunk_at_HEAD to branch_at_Z that would indeed be a problem, as any
trunk changes after Z would be removed again by the merge, but by
calculating the diff from a known fixed point on both branches (i.e.
Z), it is guaranteed to be correct. Any late changes to trunk could be
added by an update before or after the merge.
> - Commit WC to trunk
>
> ...........with the former being acceptable but more likely to result
> in conflicts during the final merge?
That sounds a pretty good summary.
> And of course, this doesn't even cover the task of continuing work on
> a branch after it's been merged back into the trunk (assuming the
> branch isn't simply discarded at that point). I guess the merge into
> trunk would result in revision N, and so after more branch changes,
> start at Step #1 above, but change that step to X = N.
Once the tree merge is complete the two trees are identical, so it
looks the same as if you had just created a branch at that point.
> Thanks for your help. I'm guessing every new user struggles just a
> little with this?
Yes, that's an understatement ;-) Once you get your head around what
is going on it makes sense, but it certainly took me a bit of head
scratching to get there. That's partly why we went for the wizard
approach in 1.5.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-11 23:42:51 CEST