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

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

From: B Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Mon, 1 Mar 2010 17:24:41 +0100

On Sun, Feb 28, 2010 at 21:33, Pacco <pacco_at_tropezien.de> wrote:
> 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.

- if you're going to put your build products under *source* control,
then by all means keep them in a separate repository.

- it doesn't make sense to spread branches belonging to one
project/package/product/whatever across more than one repository.
History does not cross repository boundaries. I'm not sure if that's
what you are suggesting...

> 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.

Within the same repository that they were just working in, I trust.

> 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.

I don't think I'm following, but it sounds like intending to merge
("compose") the BUG_***_TAG tags into your release branch for your
next release. That can be done, provided it's all in the same
repository.

> 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.

the "release repository". is this the one that gets the build products?

> So my questions are:
>
> - Is this scenario possible? Especially the cherry-picking of tags, not
> file-versions?

As far as Subversion is concerned, tags and branches are the same thing.
Bu,t I can't really answer your question because I don't fully
understand what your proposing.

> - Is there a better way of selecting individual packets (tags) for composing
> new working-directory?

I don't know, how are you going about selecting them?

// Ben
Received on 2010-03-01 17:25:17 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.