On Mon, Jan 26, 2009 at 6:27 AM, Werle, Markus <Werle_at_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_at_subversion.tigris.org].
Received on 2009-01-26 22:50:31 CET