subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From B Smith-Mannschott <>
Subject Re: SCM, Content-Management and cherry-picking in big project
Date Mon, 01 Mar 2010 16:24:41 GMT
On Sun, Feb 28, 2010 at 21:33, Pacco <> 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

> 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

View raw message