Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (athena.apache.org: domain of anpieber@gmail.com designates
 74.125.82.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4721F3A5-62CF-48D8-BE1A-ADB98044624F@yahoo.com>
References: 
 <CAK--DP_KUiMyUWSOZQxWxY+5EW_DLJ2eqbvbA8g-L5CcYBiHdw@mail.gmail.com>
	<4721F3A5-62CF-48D8-BE1A-ADB98044624F@yahoo.com>
Date: Tue, 8 May 2012 17:45:25 +0200
Message-ID: 
 <CAK--DP9KKyJrGGx4My2==GwG_Hay_LLPGqriA8o5pTAX2=mc7w@mail.gmail.com>
Subject: Re: Repository Layout
From: Andreas Pieber <anpieber@gmail.com>
To: dev@aries.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, May 8, 2012 at 5:24 PM, David Jencks <david_jencks@yahoo.com> wrote=
:
> IIUC you are proposing that we change the svn structure to work better wi=
th git by creating an svn project and git mirror for each bundle, and then =
reassembling the current project tree with aggregator poms using svn:extern=
als?

Exactly

> I don't know enough about git to know how you'd get the aggregator pom la=
yer. =A0Do you have an specific example of a project that has done this?

I have, but nothing public :-( We've worked that way at my company
before we've switched completely to git. We used repo (those python
scripts from the android project) to retrieve the correct project
(including branches and tags). For the remaining pom structure we
simply didn't cared, but rather created a small script visiting all
dirs and creating the parent pom structure back the way up it gos. In
fact you're really not interested into those
"hold-them-together-poms". You even don't release them (we'vent done
so for the svn neither; although they where checked in there).

In addition, we've used the same approach for our itests. Although
having quite a large number of bundles we hadn't had that much
versions we required to test together. E.g. to guarantee that bundle a
version x.y works with bundle b in two different version we've created
a new part in our svn called hudson where we collected all relevant
bundles with the correct branches together (using svn:external),
created the pseudo parent structure using our little script. Once
checked in automatically checks every change to the specific version
combination. Of cause for a huge number of combinations (or even all)
this is quite too much, but for our 20-30 combinations it was quite
perfect.

> I've certainly been annoyed working on felix with git that I get all of f=
elix, not just scr that I'm working on.

I second you on that :-)

> This is an interesting idea that I will have to think about some more.
>
> With the current svn structure, I think there's a tendency for release ma=
nagers to be too cautious and create a branch for a release and then a tag =
from the branch. =A0 I would prefer to just release from trunk directly. =
=A0For example I think Holly has probably more than doubled her work by cre=
ating a branch for 1.0 and now trying to merge it back.

+1

Thanks for considering and kind regards,
Andreas

>
> thanks
> david jencks
>
> On May 7, 2012, at 8:38 PM, 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[https://svn.apache.org/repos/asf/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
>