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

> -----Original Message-----
> From: Thomas S. Trias [mailto:tomtrias_at_artizan.com]
> Sent: 22 July 2009 17:21
> To: users_at_subversion.tigris.org
> Subject: Best Way to build a Release tag from cherry-picked revisions /
> changes
>
> We are using Subversion to automate the release process for our web
> applications. Currently, we have a separate branch that represents a
> site in a deployable state; changes are merged from the development
> trunk into the branch, and the result is tagged as a release. After
> several months, I have come to the firm conclusion that merges are
> overkill for this situation, and they introduce significant overhead
> (both less and more after the upgrade to 1.6 - less since 1.6 seems to
> turn merges that essentially result in copies into copies, and more
> since merging multiple revisions often has to be done one at a time due
> to "duplicate" tree conflicts).
>
> I am open to suggestion, but I think the best course of action is to
> create the Release tag as a series of copies and / or deletes; we're
> building a utility based around this that lets developers choose which
> of their revisions (and / or individual changes within a revision - not
> ideal, I know, but the flexibility is a requirement) should be applied
> onto a copy of the last Release to form the next Release. We encourage
> developers to check in frequently into the trunk (most of the changes
> are simple enough to not require a full branch, but they still may take
> a few days), so not every revision is necessarily one to be released,
> and we would like explicit confirmation from the developer that a
> change is ready for QA / Release.
>

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.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374498

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-22 19:00:05 CEST