ESOE Project on git? - ESOE Development

Message from discussion ESOE Project on git?
Received-SPF: pass (google.com: domain of s.mangelsd...@gmail.com designates 74.125.92.144 as permitted sender) client-ip=74.125.92.144;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=Wwo2ELrkwnwo+9bOjFfLDrvOvj0FDIjT1BaAAiIzbx+/rzIVR64L5ovxhB6JqRtdPH
         lfA3blaCjmJXLQimARZSgyvUgK2lS4stCrgf1B14X1qz6a+WmEhTbGCQp0TsOvOFP18z
         MZFUZrnVLSEa7TTvvqUWArMb2PX5MI/rQI2Bc=
MIME-Version: 1.0
Date: Wed, 17 Jun 2009 21:23:39 +1000
Message-ID: <90ad28f40906170423m7dc5fca1k28977c08306056a5@mail.gmail.com>
Subject: ESOE Project on git?
From: Shaun Mangelsdorf <s.mangelsd...@gmail.com>
To: esoe-dev@googlegroups.com
Content-Type: multipart/alternative; boundary=0015175ce022e4c3ed046c8985fe

--0015175ce022e4c3ed046c8985fe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi All,

It's come time again to revisit the idea of using git for development of the
ESOE project. A few things have changed since this was last discussed, not
the least of which is the transition to Redmine (http://www.redmine.org) for
managing the project.

With the revamped project site, we can now use (almost) any VCS we want. The
only feature missing is continuous integration which we can address later,
outside the scope of this discussion.

I'd be keen to hear any arguments against git, but in the absence of any
strong opposition I would say the move to git is inevitable. I believe that
tool support is now solid enough that we can make the transition smoothly.
There is one main question I put out to the esoe-dev list:

How should the Git repository be structured? I see two options really:

- One monolithic git repository with a mirror of the current structure of
the svn trunk

Advantages:
* Atomic branching and tagging, treating all the code as a unit.
* Only one history timeline to manage.
* Repository introspection will continue to function properly - Redmine can
only properly link one source repository with a project.

- One git repository per project (broken down per Eclipse project)

Advantages:
* More "correct"
* Easier for other projects to consume our code as submodules

I'm keen to hear of any more advantages to either approach, or any other
thoughts. My preference currently is for one repository, but it's certainly
not set in stone.


Regards,
Shaun Mangelsdorf

--0015175ce022e4c3ed046c8985fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,<br><br>It&#39;s come time again to revisit the idea of using git fo=
r development of the ESOE project. A few things have changed since this was=
 last discussed, not the least of which is the transition to Redmine (<a hr=
ef=3D"http://www.redmine.org">http://www.redmine.org</a>) for managing the =
project.<br>
<br>With the revamped project site, we can now use (almost) any VCS we want=
. The only feature missing is continuous integration which we can address l=
ater, outside the scope of this discussion.<br><br>I&#39;d be keen to hear =
any arguments against git, but in the absence of any strong opposition I wo=
uld say the move to git is inevitable. I believe that tool support is now s=
olid enough that we can make the transition smoothly. There is one main que=
stion I put out to the esoe-dev list:<br>
<br>How should the Git repository be structured? I see two options really:<=
br><br>- One monolithic git repository with a mirror of the current structu=
re of the svn trunk<br><br>Advantages:<br>* Atomic branching and tagging, t=
reating all the code as a unit.<br>
* Only one history timeline to manage.<br>* Repository introspection will c=
ontinue to function properly - Redmine can only properly link one source re=
pository with a project.<br><br>- One git repository per project (broken do=
wn per Eclipse project)<br>
<br>Advantages:<br>* More &quot;correct&quot;<br>* Easier for other project=
s to consume our code as submodules<br><br>I&#39;m keen to hear of any more=
 advantages to either approach, or any other thoughts. My preference curren=
tly is for one repository, but it&#39;s certainly not set in stone.<br>
<br><br>Regards,<br>Shaun Mangelsdorf<br>

--0015175ce022e4c3ed046c8985fe--