RE: Best Way to build a Release tag from cherry-picked revisions / changes

>
> God, it all sounds rather complicated! Not meshing well with source control is an indicator that things might not be arranged optimally...
>
> The way we handle releases is that everyone develops on the trunk, then, once we have decided to do our first release we create our Release_1.0 branch. Some people move onto that branch and start bugfixing and QAing. Meanwhile dev continues on the trunk towards the 2.0 release. Periodically (maybe once a week) we batch merge everything down from the Release_1.0 branch down to the trunk. At this point, if we want to cherry pick and say that something shouldn't go into 2.0 (very unusual) then we don't merge it back (but we do update the mergeinfo to pretend that its been merged back). Once 1.0 has gone out and we create a 1.1 branch off 1.0. Then we do the whole thing again feeding changes to the parent branch until it gets to the trunk. Occasionally we will also port a fix from the trunk onto a release branch, but its nice to try and keep the traffic one way for simpler merges.
>
> It works nicely and meshes well with source control.

I agree that the apparently complicated result is less than ideal, but it actually ends up being simpler to manage, implement, and report upon, with less overhead than full-blown merges, and it gives an accurate picture of what is marked ready for release with full auditing and log traversal. Merge's biggest advantage as far as building releases is concerned is the fact that is is already built into subversion; as far as building a release is concerned, I can't think of any other advantage merge has over the copy process. Since we're building a set of GUI tools (standalone and integrated with TortoiseSVN; Visual Studio TBD) to integrate with our automated deployment system, our interface will be simpler for the developers to use (since it has a very specific purpose). The main issue with using merges is the fact that our developers work on the trunk, committing frequently, often using a shared working copy (yes, I know, but old habits die hard and we are still maintaining classic ASP sites that do not len
d themselves to distributed development due to complicated environmental constraints). Couple that with one-off copies and refactoring within the trunk itself, and the merge becomes difficult and confusing to many of our developers. We are working to make things easy on them (so that the right workflow becomes the natural workflow), while still meeting the audit trail and log reporting goals of our deployment process.

We're currently using the merge method you described above, which let the developers pick and choose what changes to merge via revision arguments and individual edits and reverts; we cannot just merge the entire trunk because it is likely that there are intermediate check-ins that are not yet ready for release. The intermediate check-ins are crucial! If someone is working on a problem and they write code that turns out to be a false start / dead-end, we still want it committed to the repository so that we can revisit it or apply the techniques used somewhere else.

We could separate each person's work into feature / developer branches (although this becomes tricky when working in a shared working copy on the web server), but all that does is move the complicated merge from trunk -> release to feature -> trunk, and then we perform a trunk -> release copy. Barring catastrophic bugs (which aren't supposed to be released anyway ;-), most fixes are made directly on the trunk along with work for the next release. Since most of our web applications are deployed to clusters under our control, releases are very frequent, so fixes and enhancements get pushed without the need for a separate patch vs. release process.

The merge process requires separate working copies for merges, leading to an extra 300+ MB (and counting) per WC and associated network overhead for updates and merges; many of our developers (myself very much included) work remotely via VPN for one or more days a week, so minimizing network overhead is ideal.

The fact is, the only actual changes that should ever be applied to a release (well, QA in an ideal world) are bug fixes; an actual base release can (and will, from our standpoint) be represented strictly by copies and deletes from the previous release / base revision. Once I have the base design working, I can show you how it looks from a repository management / reporting standpoint, and we can continue our debate. :-)

The need for frequent intermediate changes is luring me towards a DVCS, but that would most likely result in a full-scale developer revolt. With a DVCS, the Release would be a separate repository (and working copy all rolled into one), and Development repository changes would get merged to the Release repository via a mechanism quite similar to the cherry-picking described above. :-)

Forgive my ramblings; I tried to reorganize them into a coherent sequence,

-- 
Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374535
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].