[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SCM, Content-Management and cherry-picking in big project

From: pacco <pacco_at_tropezien.de>
Date: Mon, 01 Mar 2010 08:04:11 +0100

Hi,

I'm responsible for the content of a single package within a bigger
software (several million lines of code). I'm experienced with
ClearCase, Dimensions, CVS, git, mercurial, etc.
Now, management decision was made to use Subversion over one of the big
players.
But on opposite side I'm confronted with customer's request of stable
releases, quick and immediate rollbacks, multiple release branches.

So, I want to get the very best out of Subversion from the Content
Management point of view. I want individually select changes for my
release version.
My intentional idea looks like that:

1) Multiple repositories for release-results (binaries, libraries),
development of different package-branches, etc.

2) Developers are working on one repository. After having made their
implementations or changes, they commit and copy/create a tag-version,
i.e. BUG_1234_TAG.

3) Official release planning:
Based on last release-branch, i.e. REL_0001, I want to compose the next
release by individually taking the different tags. For example:

   REL_0000 (old release)
   BUG_1010_TAG
   BUG_1020_TAG

but not BUG_1030_TAG and BUG_1040_TAG.
Unfortunately I'm not aware of the commiting order! BUG_1010_TAG could
have been commited after BUG_1020_TAG.

4) After populating this release-working-directory, the official builds
and tests are done. A tag or branch will be copied to mark this
release-version, the release outcome are commited to the release-repository.

So my questions are:

- Is this scenario possible? Especially the cherry-picking of tags, not
file-versions?
- Is there a better way of selecting individual packets (tags) for
composing new working-directory?

-- 
Pacco
Received on 2010-03-01 08:04:50 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.