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

RE: Multiple teams + Different Build Options + One Repository?

From: Shaun Pinney <shaun.pinney_at_bil.konicaminolta.us>
Date: Thu, 10 Sep 2009 20:24:39 -0700

Hi Andrey,

Thanks for the response! Sorry, maybe I could have chosen the subject line
better :)

I like the single script idea but, unfortunately, we cannot auto-configure
the correct team settings based solely on the build environment info. So
maybe branching can provide the solution. Can you let me know if I
understand your idea correctly?
Say we have our config files, /trunk/foo/buildFoo.bat and
/trunk/foo/h/config.h, and source files in /foo which are built by
buildFoo.bat and which include config.h.


We'd create a branch of buildFoo.bat for each team, modify them to contain
each team's settings, and commit:


Next, I'd imagine if we're creating branches for each team we'd remove
/trunk/foo/buildFoo.bat and /trunk/foo/h/config.h to avoid duplication in
SVN. Before building we'd probably create a new script to copy all
configuration files from "teamN/" to their original locations (to avoid
modifying any Makefiles due to moving files from their original locations
into 'teamN' directories). So the build process would be to checkout, run
the 'team select' script to copy files from "teamN/" to correctly locations,
and then run buildFoo.bat from /trunk/foo/buildFoo.bat, as we currently do.
Also, the sources would still remain in the trunk.


At first glance, I like a lot about this idea. It gives each team a single
directory to modify every configuration file. It does not require any
Makefile changes, since even though configuration files are moved to new
locations, they are copied to their original locations before building.
That means we do not need to change our current build procedure, other than
to select the desired 'teamN' configuration. Plus, it allows changes from
one team to be viewed by the other with a simple SVN Update (which is what
we want, AFAIK. Could change tomorrow, who knows? :). I've elaborated a
bit beyond your suggestion with the team select script, I know, but does
this seem sane?

Please let me know if I have the right understanding.


-----Original Message-----
From: Andrey Repin [mailto:anrdaemon_at_freemail.ru]
Sent: Thursday, September 10, 2009 6:04 PM
To: Shaun Pinney; users_at_subversion.tigris.org
Subject: Re: Multiple teams + Different Build Options + One Repository?

Greetings, Shaun Pinney!

> In-Reply-To: <E4A238AC-23F1-4149-9B48-4B506B16A5EE_at_ryandesign.com>
> References: <h88eu1$k8v$1_at_ger.gmane.org>
> <h8b5f9$n93$2_at_ger.gmane.org>
> Subject: Multiple teams + Different Build Options + One Repository?

First and foremost, please start a new thread by writing a new message
of linking deep into unrelated discussion.

> Quick question. We have an SVN repository and are preparing to provide
> access to another development team. An issue which has come up is our
> software has many build options controlled by a few scattered files and
> team needs different build options. Can we provide both teams a way to
> checkout the latest source code, but with different build options? I
> we should be able to reduce configuration errors by giving the right build
> options to the right team automatically upon checkout, compared to a
> approach of everyone editing on each checkout. Is there a clever solution
> for this (e.g. svn:externals)? Thanks for any advice!

If you need a different building scripts, I think it would be better to
branch them for every team, unless it is possible to maintain a single
that automatically configure itself for the environment it running in.

 Andrey Repin (anrdaemon_at_freemail.ru) 11.09.2009, <5:00>
Sorry for my terrible english...
To unsubscribe from this discussion, e-mail:
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-11 05:26:37 CEST

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.