[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rmf-dev] proposal for simplifying git repository structure

Dear all,

I did some experiments on how we can merge the repositories. Pseudo code see below.

It is really simple:

(0) Make sure that all development branches of 'old' repositories are merged into the master. 
(1) create the new Eclipse repository org.eclipse.rmf.git
(2) clone the new repository
      git clone ssh://git.eclipse.org/gitroot/rmf/org.eclipse.rmf.git
(2) clone the old repositories
      git clone ssh://git.eclipse.org/gitroot/rmf/org.eclipse.modeling.rmf.core.git
      git clone ssh://git.eclipse.org/gitroot/rmf/org.eclipse.modeling.rmf.core.reqif10.git
      git clone ssh://git.eclipse.org/gitroot/rmf/org.eclipse.modeling.rmf.core.rif11.git
      git clone ssh://git.eclipse.org/gitroot/rmf/org.eclipse.modeling.rmf.core.rif12.git
      git clone ssh://git.eclipse.org/gitroot/rmf/org.eclipse.modeling.rmf.pror.reqif10.git
(3) now you should have the following folders
(4) cd org.eclipse.rmf
(5) git fetch ../org.eclipse.modeling.rmf.core ; git merge FETCH_HEAD ; git push origin master
(6) continue with the other repositories

done :-) 

regards mark

Am 27.01.2012 um 18:19 schrieb Michael Jastram:

Dear all,

I did some archeology.  I brought up the issue back in June 2011, before
we had a mailing list (and when we still considered migrating to Eclipse

We have a number of loosely coupled projects.  My suggestion would be
to manage them all in one single Eclipse Labs project, but with a
separate mercurial repositories for each project.  Does this approach
make sense?

... but there was little response, no objection either.  Wayne was part
of that discussion.  The fact that he didn't object reflects what he
said in [1].  Other projects picked a similar approach, e.g. Hudson.
The motivation was the relative independence of the five projects.
Also, two projects will probably not see that much activity (rif11 and

I find the current configuration useful and the overhead minor.
Checking out a few repositories has to be done only once, and the
tagging for the release process should eventually be done with scripts

But I am also in favor of simplicity.  So if there is a real *strong*
desire to merge the repositories, I'll be fine with that.  So... how
strong is that desire?

I suggest to have separate repositories for product code, incubation
and deprecation.

This is certainly something to consider once we leave incubation.  For
now, I don't think this is necessary.


- Michael

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=345471

Michael Jastram (http://www.jastram.de, +49 (162) 274 83 94)
Geschäftsführer, Formal Mind GmbH (http://formalmind.com)
Wissenschaftler, Heinrich Heine Universität Düsseldorf (http://www.stups.uni-duesseldorf.de)
1. Vorsitzender, rheinjug e.V. (http://www.rheinjug.de)

rmf-dev mailing list

Mark Brörkens
Softwarearchitekt, Projekt- und Produktmanager

Telefon:  +49 30 69 535 878
Telefax:  +49 30 62 908 067
Mobil:     +49 151 61301259 (bevorzugt)

itemis AG
Niederlassung Berlin
Ohlauer Straße 43
10999 Berlin

Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus