aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Repository Layout
Date Tue, 08 May 2012 15:37:16 GMT
+1, we've been using this approach in the JBoss OSGi Framework as
well, although purely in Git, without an SVN counterpart.
The way it works for us by having an umbrella project [1] which either
depends on released versions of a subproject (so it pulls them in via
Maven), or, if a subproject is still being developed it uses a git
submodule to pull in an unreleased version of the codebase.
The umbrella project has a pom that can build the unreleased
submodules as part of the overall build, see [2] for an example...

Cheers,

David

[1] https://github.com/jbosgi/jbosgi
[2] https://github.com/jbosgi/jbosgi/blob/2505a3ad07a0255cf3baf3fdcf1c19940e83becc/reactor/pom.xml

On 8 May 2012 16:24, David Jencks <david_jencks@yahoo.com> wrote:
> IIUC you are proposing that we change the svn structure to work better with git by creating
an svn project and git mirror for each bundle, and then reassembling the current project tree
with aggregator poms using svn:externals?
>
> I don't know enough about git to know how you'd get the aggregator pom layer.  Do you
have an specific example of a project that has done this?
>
> I've certainly been annoyed working on felix with git that I get all of felix, not just
scr that I'm working on.
>
> 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 managers to be
too cautious and create a branch for a release and then a tag from the branch.   I would
prefer to just release from trunk directly.  For example I think Holly has probably more
than doubled her work by creating a branch for 1.0 and now trying to merge it back.
>
> 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
>

Mime
View raw message