> -----Original Message-----
> From: Thomas S. Trias [mailto:tomtrias_at_artizan.com]
> Sent: 22 July 2009 20:00
> To: users_at_subversion.tigris.org; James French
> Subject: 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 lend 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,
>
I think we inhabit very different worlds. Mine is all about delivering a range of desktop installers and zipped software SDKs, with each release being separated by weeks, possibly months - very different to website deployment which I have no experience of. I guess the thing I find weird is that release bug fixes are done on the trunk, where we would do them on a release maintenance branch and propagate them back to the trunk, where general development happens.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374698
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-23 10:43:13 CEST