Gennaro Prota wrote:
Daryle Walker wrote:
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote: [...]
where does the release branch originate from?
It's always from the previous release.
Is this a good thing?
Not to me. I imagine that, in a time in which I wasn't following the list, there have been long discussions which led to the current state of affairs. So, it may be clear to everyone except me. What I know for sure is that this requires *a lot* of work every time you make a modification; and either a lot of memory on your part, or a file where you note the inter-release changes down, detailedly (I certainly don't trust merging a whole directory (or multiple ones) blindly: I want to see exactly what gets merged; and, to do this, I have to keep a list of what changes I made). With such an approach, I'd expect more problems due to naive merges than problems due to an unstable trunk version being used as a branch point.
Whoa! None of that has to be done manually. Subversion provides plenty of tools to manage differences between trunk and branches/release. There are several ways to go about merging. One procedure is to switch your working copy to branches/release, merge changes from branches/release to trunk into your working copy, and then view the differences. The only thing even remotely tricky is to remember the diff to be merged is from branches/release to trunk, not the other way around. If all changes are to be merge, you are ready to commit. But if only some changes are to be merged, or just to be sure, I view the diff between the merged but not yet committed working copy and the repository. On Windows, I prefer a GUI approach, so use TortoiseSVN configured with Beyond Compare as the diff viewer and editor. If there are specific changes I don't want moved to branches/release, it is easy to revert (select, click the <- button) those specific changes. Save. Commit. --Beman