You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Werle, Markus" <We...@fev.de> on 2009/01/26 14:27:20 UTC
Configuration and build management - how?
Hi!
I have some questions concerning configuration management.
We have a large project with a rather large set of different
executables, which share a large set of common code, which we want to
build up using very small modules.
So we have approximately this kind of repo structure:
MASTER
|--Common
| |--Module1
| | |--trunk
| | |--Module1
| | |--branches
| | |--Module1_Branch_1
| | |--Module1_Branch_2
| |--Module2
| |--trunk
| |--Module2
| |--branches
| |--Module2_Branch_1
| |--Module2_Branch_2
|--Tools
| |--Tool1
| | |--trunk
| | |--Tool1
| | |--branches
| | |--Tool1_Branch_1
| | |--Tool1_Branch_2
| |--Tool2
| | |--trunk
| | |--Tool2
| | |--branches
| | |--Tool2_Branch_1
| | |--Tool2_Branch_2
etc.
The advantage of this approach is that we are rather flexible with
regard to true configuration management for a build system.
Tool1 in branch Tool1_Branch_1 may have references to Module1 branch
Module1_Branch_2 and Module2 branch Module2_Branch_1 and so on.
Note that it is required and perfectly OK for us to have ToolX probably
refer to a very old version of a module in the Common tree. Therefore
switching to a more agile process where each tool uses the latest and
greatest version of the Common stuff and using a structure like this
MASTER
|--trunk
|--branches
|--etc.
is not what we can afford due to potential of massive interface changes
in the Common modules. Also we'd like to code, not to merge most of the
time.
Everything is fine until the day when you start the tortoise repo
browser and ask for a checkout of MASTER. Now you find that every
single branch (and tag!) of every module and tool is checked out until
a "file system full" message appears.
What I want is the ability to configure special "tags" which lead to a
checkout of a distinct set of branches below master, e.g. a checkout of
Tool1 branch Tool1_Branch_1 together with Module1 branch
Module1_Branch_1 and Module2 trunk.
I wondered if I could abuse externals, but since externals are
externals and point to absolute addresses the whole game blows up if
the repository migrates from filesystem to server or later to an other
server.
The longer I think about it I do not see any satisfying solution on how
to
filter the checkout. Checking out 200 modules by hand is tedious ...
At least is there some "check out only trunk branches" command
available?
I found this unanswered post at
<http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=466666&dsFor
umId=1065>
and got the impression that I am in the same boat somehow.
Any ideas how to address this issue?
Build my own SCM on top of subversion using the API?
Am I to reinvent the wheel?
Any help appreciated.
best regards,
Markus
------------------------------------------------------------------
FEV Motorentechnik GmbH Telefon +49 241 5689-0 Telefax +49 241 5689-119
52078 Aachen Neuenhofstr. 181 Internet:http://www.fev.com
Handelsregister Aachen HRB 1649 / Geschäftsführer: Prof. Dr.-Ing. Stefan Pischinger, Dr.-Ing. Ernst Scheid, Dr.-Ing. Markus Schwaderlapp, Dipl.-Ing. Rainer Paulsen, Gary W. Rogers / Beiratsvorsitzender: Prof. Dr. techn. Dr. e.h. Franz Pischinger
Vertraulichkeitsinformation:
Diese Nachricht ist vertraulich. Die Informationen dieser Nachricht sind ausschließlich für die persönliche und vertrauliche Verwendung durch den/die oben genannten Empfänger bestimmt. Wenn Sie kein beabsichtigter Empfänger sind, bitte lesen, kopieren und verwenden Sie die Nachricht nicht. Machen Sie sie nicht anderen zugänglich. Bitte informieren Sie uns umgehend über den Zustellfehler und senden Sie die Originalnachricht per E-Mail an uns zurück.
Confidentiality Notice:
This message is confidential. The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If you are not the intended recipient, please do not read, copy, or use it and do not disclose it to others. Please inform us immediately of the delivery error and return the original message to us via e-mail.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1054839
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Configuration and build management - how?
Posted by Hari Kodungallur <hk...@gmail.com>.
On Mon, Jan 26, 2009 at 6:27 AM, Werle, Markus <We...@fev.de> wrote:
> Hi!
>
> I have some questions concerning configuration management.
>
> We have a large project with a rather large set of different
> executables, which share a large set of common code, which we want to
> build up using very small modules.
>
> So we have approximately this kind of repo structure:
>
> MASTER
> |--Common
> | |--Module1
> | | |--trunk
> | | |--Module1
> | | |--branches
> | | |--Module1_Branch_1
> | | |--Module1_Branch_2
> | |--Module2
> | |--trunk
> | |--Module2
> | |--branches
> | |--Module2_Branch_1
> | |--Module2_Branch_2
> |--Tools
> | |--Tool1
> | | |--trunk
> | | |--Tool1
> | | |--branches
> | | |--Tool1_Branch_1
> | | |--Tool1_Branch_2
> | |--Tool2
> | | |--trunk
> | | |--Tool2
> | | |--branches
> | | |--Tool2_Branch_1
> | | |--Tool2_Branch_2
>
> etc.
>
> The advantage of this approach is that we are rather flexible with
> regard to true configuration management for a build system.
>
> Tool1 in branch Tool1_Branch_1 may have references to Module1 branch
> Module1_Branch_2 and Module2 branch Module2_Branch_1 and so on.
This is a neat structure. But I think the repository structure (regarding
where you place the branch etc) is more of a matter of taste and also how
independent these modules are. For example, you could have a similar
structure within a top level 'branches' directory. Wherever you place the
branch, your build / checkout scripts will need to have the knowledge of
where it check it out from.
>
>
> Note that it is required and perfectly OK for us to have ToolX probably
> refer to a very old version of a module in the Common tree. Therefore
> switching to a more agile process where each tool uses the latest and
> greatest version of the Common stuff and using a structure like this
>
> MASTER
> |--trunk
> |--branches
> |--etc.
>
> is not what we can afford due to potential of massive interface changes
> in the Common modules. Also we'd like to code, not to merge most of the
> time.
>
> Everything is fine until the day when you start the tortoise repo
> browser and ask for a checkout of MASTER. Now you find that every
> single branch (and tag!) of every module and tool is checked out until
> a "file system full" message appears.
>
> What I want is the ability to configure special "tags" which lead to a
> checkout of a distinct set of branches below master, e.g. a checkout of
> Tool1 branch Tool1_Branch_1 together with Module1 branch
> Module1_Branch_1 and Module2 trunk.
>
> I wondered if I could abuse externals, but since externals are
> externals and point to absolute addresses the whole game blows up if
> the repository migrates from filesystem to server or later to an other
> server.
>
> The longer I think about it I do not see any satisfying solution on how
> to
> filter the checkout. Checking out 200 modules by hand is tedious ...
>
> At least is there some "check out only trunk branches" command
> available?
>
>
> I found this unanswered post at
> <http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=466666&dsFor
> umId=1065<http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=466666&dsForumId=1065>
> >
> and got the impression that I am in the same boat somehow.
>
> Any ideas how to address this issue?
> Build my own SCM on top of subversion using the API?
> Am I to reinvent the wheel?
> Any help appreciated.
>
As far as I know there is no command within svn that will provide you with
this functionality to checkout a project and all its dependencies. You might
be able to achieve it using some scripts that is on top of the basic svn
command set.
You could use externals as well. As long as you don't abuse it and manage it
well, it works well. But if you are looking for being 'agile' and being able
to mix and match revisions many times for testing, the externals might
actually come in your way.
regards,
-Hari
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1056161
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].