aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <>
Subject Re: Repository Layout
Date Fri, 11 May 2012 11:32:53 GMT
@Holly: v1.0.0 first is fine anyhow since we already required it
desperately for Karaf :-)

IFF there are no branches (neither for releases (as Holly pointed out)
nor for maintenance (as Guillaume pointed out)) AND there is a
subfolder per bundle in the tags dir (where I can point the mirror to
search it's tags) AND every bundle is tagged in a single commit I'm
fine with it as it is. Infra can setup quite a pretty mirror structure
than by bundle. But if one or more of the above conditions is not
fulfilled we need to continue the discussion since it will otherwise
always create really crappy git mirrors. And tbh I think that bad git
mirrors result from not holding tightly to "how svn should be used".

Kind regards,

On Fri, May 11, 2012 at 11:27 AM, Guillaume Nodet <> wrote:
> If the problem is mainly about being able to maintain branches, I think the
> discussion needs to be about that first, i.e. how can we maintain branches
> ?  The previous decision was that there was no need to do so and the strict
> semantic versioning that has been decided does not leave such room anyway.
>  So unless this is revisited, I don't see why we'd have to change the svn
> layout.
> On Tue, May 8, 2012 at 5:38 AM, Andreas Pieber <> wrote:
>> 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,
>> Andreas
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> FuseSource, Integration everywhere

View raw message