Nicklas,
we have a comparable situation here although much simpler (we have about 4
levels in the pyramid, but created only two in svn).
What we did was to group the modules depending on their 'levels' within the
pyramid and logical cohesion.
So we have in subversion
trunk/MAL (this is contains the 4 or 5 top level modules which together form
one product)
trunk/components (this contains the lower level modules)
In the future we foresee to add
trunk/xyz (a new product)
that also builds on the components.
With this it is possible to have these groups of modules at different
revisions and to work on the components without needing MAL.
However, due to our build system it is required that components is a sub
directory of MAL. For that we use svn:externals, which works well. The
advantage and disadvantage is that commits of MAL do not descend into
components. It is an advantage because now MAL developers do not by accident
commit changes in components (which they shouldn't be doing). But it is also
a disadvantage because changes to both (for example an external interface of
components) cannot be in one commit.
If there were multiple levels in the tree, using svn:externals would
automatically checkout and update the required externals for that level (of
the pyramid) and recursively all required sublevels. That'll be the largest
problem you'll face if your using a flat svn layout. One might get changes
in one level that require changes at another level, but since there are no
dependencies, one needs to figure that out manually each time. We fixed it
by using externals and, in hindsight, I can say that we put it at the proper
place in the pyramid.
At the moment we're in the testing phase and we build releases from the
trunk using 0.0 as release number and the svn revision as build number. So
trunk releases are always 0.0.xyz (using output of svnversion)
Since the components are external to MAL, we'll start to make proper 1.0
releases soon and MAL will use one of those as svn:external, allowing
development of components to continue.
Later on when MAL releases are build, it is quite possible that MAL 1.0 uses
components 1.1. A proper release is number x.y with x>=1. In this situation,
svnversion -c is used.
This scheme allows us to automatically generate the version numbers and thus
reducing manual operations and chances of failure.
This is what our svn:externals looks like right now:
[issysd25@a05008 mal]$ svn pl . -v
Properties on '.':
svn:externals : "components
http://a05009.aex.nl:65030/svn/MAL2/products/trunk/components"
(I added the double quotes in the previous line to show what it is set to).
This creates the components subdirectory containing whatever is in the given
URL.
Hope this helps a bit.
Jan Evert
> -----Original Message-----
> From: Nicklas Norling [SMTP:nicklas.norling@ifsab.se]
> Sent: Tuesday, March 23, 2004 10:41 AM
> To: 'users@subversion.tigris.org'
> Subject: Modular repository layout advice
>
> Hi.
>
> I'd like to hear if anyone has any experience with a modular layout in the
>
> subversion repo.
>
> I've got this rather large application consisting of modules. Some of
> these
> modules are base modules, they provide the foundation for the others, or
> are at the bottom of the dependency pyramid if you will. Others then
> depend
> on these and also provide the basic features for yet another layer of
> modules.
> Like a pyramid, or terass if you will.
>
> Since checking out all these modules will be quite a large amount of code
> I'd like to organize the repo in such a way that developers can pick and
> choose
> what they want.
> E.g. a developer of the basic modules might only want his/her basic
> modules,
> and perhaps one or two dependant modules to be able to verify their
> changes.
> The developers on modules higher up in the hierarchy might want the basic
> modules,
> their own modul(s) and possibly some upstream modules. The developers of
> the
> modules highest in the dependencies would want only their module(s) and
> the rest
> should be as stabile as possible.
>
> Currently I have the following proposal of the layout of the working copy
> from my
> developers (they use some tools that makes this layout beneficial).
>
> <workspace>
> <dev_root>
> <module1>
> <module2>
> ...
> <moduleX>
>
> I've been reading the svn book and thought of:
>
> /trunk/module1
> /trunk/module2
> ...
> /trunk/moduleX
>
> Developers would then get all code, but they can pin some of the modules
> to
> specific version so that the base is not moving while developing higher
> modules.
> Judging from performance of recursive operations in subversion I'm not
> sure this
> is possible at all. There will be over a gig of files, probably close to
> 100k files in
> 10k folders. Would commit/update etc. work on that?
>
> Also thought of this (from svn book):
>
> /module1/trunk/
> /module2/trunk/
> ...
> /moduleX/trunk/
>
> That's really a sexy solution in my eyes, it's like a smorgasbord where
> developers
> can pick and choose what every modules they need. They can still pin them
> to specific
> version if they want. Modularized even in subversion.
>
> But, I can't figure out how to check this code out. It's not possible to
> check out modules
> in a parallel if I understand correctly, at least TSVN appears to be
> grayed out in such
> a situation.
> So I looked at svn:external, but I can't seem to get it to work either.
> Externals seems
> useless when it comes to modules like this, it will only work if I have
> subfolders in an
> already existing modules, and then the modularization is gone.
>
> While I have presented you with what I want, and what I've got, there is
> certainly room for
> change. But somehow the modularization has to be maintained. I can't seem
> to figure
> out how to use subversion to do this in a nice way.
>
> Does anyone have any ideas on how to do this?
> Maybe there are people out there with experience with this sort of
> modularization?
> I would love to hear your feedback as I've been unable to find anything
> like this on the net.
>
> Thanks!
> /Nicke
>
=== E U R O N E X T - D I S C L A I M E R =============================
This e-mail and its attachments are only intended for the individual(s) or
entity(entities) named above to whom they are addressed and may contain
personal and/or confidential information. Please notify us immediately if
you are not the intended recipient. Any dissemination, duplication,
publication to third parties or other use of the contents of this e-mail or
its attachments is forbidden. Although this information has been compiled
with great care, neither Euronext N.V. nor its subsidiaries shall accept any
responsibility for any errors, omissions or other inaccuracies in this
information or for the consequences thereof, nor shall it be bound in any
way by the contents of this e-mail or its attachments. In the event of
incomplete or incorrect transmission please return the e-mail to the sender.
Cet e-mail et ses annexes sont uniquement destinés à la (aux) personne(s),
ou à l' (aux) entité(s) à laquelle (auxquelle(s)) il est adressé, visée (s)
en tête du présent message. Il peut contenir des informations personnelles
ou confidentielles. Merci de nous notifier immédiatement si cet e-mail vous
a été adressé par erreur. Toute diffusion, copie, publication à des tiers ou
toute autre utilisation de son contenu est interdite. Bien que cette
information ait été rassemblée avec une grande attention, ni Euronext N.V.
ni aucune de ses filiales, ne peut être tenue responsable des erreurs,
omissions ou inexactitudes contenues dans cette information, ni ne peut être
liée d'aucune manière par le contenu de cet e-mail ou ses annexes. En cas de
transmission incorrecte ou incomplète, nous vous prions de retourner cet
e-mail à son émetteur.
Deze e-mail en zijn bijlagen zijn uitsluitend bestemd voor de
geadresseerde(n) als op dit e-mailblad vermeld. Het is mogelijk dat deze
e-mail persoonlijke en/of vertrouwelijke informatie bevat. Wanneer u niet de
geadresseerde bent, verzoeken wij u dringend ons daarvan te berichten. Elke
verspreiding, vermenigvuldiging, gebruik of openbaarmaking aan derden van de
inhoud van deze e-mail en zijn bijlagen, is verboden. Hoewel deze informatie
met de meeste zorg is samengesteld is Euronext N.V., en de tot Euronext N.V.
behorende werkmaatschappijen, op geen enkele wijze aansprakelijk voor
eventuele fouten, omissies of andere onjuistheden in deze informatie of de
gevolgen daarvan noch op enigerlei wijze gebonden aan de inhoud van de
e-mail of zijn bijlagen. Gelieve, in geval van onjuiste of onvolledige
ontvangst, deze e-mail terug te sturen naar de afzender.
================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 11:09:20 2004