aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <>
Subject Repository Layout
Date Tue, 08 May 2012 03:38:25 GMT
Hey Aries Team,

I follow the dev list for several months now (actually as it still was
in incubator) and I know the topic was on the dev list (in one or the
other way) several times by now. Nevertheless, since I start using
Aries more and more in source level and building each project for
itself it starts nagging more and more on me: the current way of
handling branches and tags. On one hand each project is handled on
it's own, on the other hand they're mixed in different ways all over
the project. For example release branches are started sometimes by
creating a new folder and copying over all projects to release.
Sometimes single branches are copied, sometimes everything. Imagine
for one moment how this will result in the history for a single
project (or a git-mirror for a single project in may case):
catastrophic. There are dangling branches (tons of them), unnecessary
commits mangled up, no clear way to find release tags of a single
project and so on.

Before I wrote this mail I scanned the mailing lists again for the
several options and the reasons not to create trunk/branches/tags per
project, but in all those discussions there was one version not
brought up to the table, which would allow both; a) a clean and
correct repository layout AND b) the option to commit to several of
them quite easily at once AND c) create arbitrary branches as they're
required, over several branches: Why not using svn:externals to
structure the repository as required. We could create
ARIES[]projects which contain
e.g. ARIES/blueprint/blueprint-core/trunk_tags_branches and so forth.
Then we create ARIES/trunk where the project is added as svn:external
in blueprint/. That way there could be a complete super-pom-structure
which would allow to compile all projects (and release them at once).
In the same manner ARIES/branches could create any folder combination
liked containing the required projects as svn:externals instead of
real projects. The projects would still stay in ARIES/projects in a
completely correct structure which could a) be easily mirrored by git
and b) will always present a correct single project history.

Why I bring this up exactly now: because Holly has started some weeks
ago to preparing the 1.0.0 releases of Aries and I think directly
after a merge, but before the release would be a good chance to change
the repository layout once more.

I know that e.g. Felix and ACE don't do it that way, but e.g. SMX does
some parts in quite similar way (yes there are differences, but
conceptionally they do something quite similar), so it seams that
there is room for more than one solution, and the one I proposed would
definitely be the best for us poor git-svn users but should still be
working fair enough for SVN users. In addition it will help
structuring the repositories a) per project and b) still per context.

Kind regards,

View raw message