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 209.85.221.201 as permitted sender) client-ip=209.85.221.201;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=gXqCYgItREE+OhKiUhkZ8B2qedF17yGBVElQezRT9Hvi4S8UZpmAAsInS0U6L+J21p
         PHJadoYlMV9nssyxm50KsahWM69msf6JfQnQWOSqFSO0cHajQ966rpqgUsjkWzRzg8J9
         tc0af3GqfWQaPwQKbzWSDv4RI1f6K2ERU7zdQ=
MIME-Version: 1.0
In-Reply-To: <070F1BDA-96E8-4845-92FE-F74B2982F9E8@gmail.com>
References: <90ad28f40906170423m7dc5fca1k28977c08306056a5@mail.gmail.com>
	 <9C5E4D8B-FA0E-4CEF-8782-16C1D6477969@intient.com>
	 <070F1BDA-96E8-4845-92FE-F74B2982F9E8@gmail.com>
Date: Thu, 18 Jun 2009 18:41:05 +1000
Message-ID: <90ad28f40906180141r49a1f64eic371c496064f1...@mail.gmail.com>
Subject: Re: [esoe-dev] Re: ESOE Project on git?
From: Shaun Mangelsdorf <s.mangelsd...@gmail.com>
To: esoe-dev@googlegroups.com
Content-Type: multipart/alternative; boundary=0015175cd5bc5b5452046c9b5e90

--0015175cd5bc5b5452046c9b5e90
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

2009/6/18 Luke Daley <lda...@gmail.com>
>
> This does cause issues with branching/tagging etc, but it may be a
> good opportunity to investigate whether all of the modules need to be
> bound to the same version number and release cycle.


Good point here, though certain projects are coupled tightly enough that
they should be in sync - for example:
esoecore + esoemanager + esoedeployer
spepjava + spepjavafilter
spepcpp + modspep + spepcppdaemon

Putting some effort into decoupling them might lessen the impact, but the
dependency will still be there.

If a monolithic repository can be avoided, I think that should be the
> path.


Personally I believe we need to go with whatever is going to be easier to
work with.

Aside from personal preference, what advantages do you see with individual
repositories?

> What I find does really get painful with the single repository
> > approach is folks storing binaries (jars etc) that cause pulls to take
> > a long time especially from international sources. ESOE to date has
> > done a very good job of not storing any binary in SCM and has made
> > good use of Ivy et al for dependency resolution.
>
> This is painful even with multiple. But at least with multiple you can
> isolate the pain.
>
> For example, the Grails plugin does have binaries in svn.
> Unfortunately this is really unavoidable. If it was it's own repo it
> wouldn't be infecting the whole project.


Binaries in the repository are probably a moot point - either way we need t=
o
invest some effort into keeping them out. I agree that doesn't change
whether we use single or multiple repositories.


> GitHub is a lot more useful as a web-app with single repository in my
> > experience.
>
> Can't you emulate a lot of this by a =93meta=94 project that pulls
> everything in as a module?


Unfortunately by doing it that way you lose the ability to properly
introspect project history, the ability to link commits/diffs to issues and
other such niceness.

If I may quote you from last time we had this discussion, "Having the diffs
and build results functionally linked to tickets/features is more beneficia=
l
than whatever vcs is in use in my opinion. If there is going to be a change
then we should try to get a good _suite_ of tools happening."

Having a suite of tools at our disposal is the main factor swaying me
towards a monolithic repository.


Shaun

--0015175cd5bc5b5452046c9b5e90
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2009/6/18 Luke Daley <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lda...@gmail.com" target=3D"_blank">lda...@gmail.com</=
a>&gt;</span><blockquote class=3D"gmail_quote" style=3D"border-left: 1px so=
lid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


This does cause issues with branching/tagging etc, but it may be a<br>
good opportunity to investigate whether all of the modules need to be<br>
bound to the same version number and release cycle.</blockquote><div><br>Go=
od point here, though certain projects are coupled tightly enough that they=
 should be in sync - for example:<br>esoecore + esoemanager + esoedeployer<=
br>

spepjava + spepjavafilter<br>spepcpp + modspep + spepcppdaemon<br><br>Putti=
ng some effort into decoupling them might lessen the impact, but the depend=
ency will still be there.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex=
; padding-left: 1ex;">


If a monolithic repository can be avoided, I think that should be the<br>
path.</blockquote><div><br>Personally I believe we need to go with whatever=
 is going to be easier to work with.<br><br>Aside from personal preference,=
 what advantages do you see with individual repositories?<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
&gt; What I find does really get painful with the single repository<br>
&gt; approach is folks storing binaries (jars etc) that cause pulls to take=
<br>
&gt; a long time especially from international sources. ESOE to date has<br=
>
&gt; done a very good job of not storing any binary in SCM and has made<br>
&gt; good use of Ivy et al for dependency resolution.<br>
<br>
</div>This is painful even with multiple. But at least with multiple you ca=
n<br>
isolate the pain.<br>
<br>
For example, the Grails plugin does have binaries in svn.<br>
Unfortunately this is really unavoidable. If it was it&#39;s own repo it<br=
>
wouldn&#39;t be infecting the whole project.</blockquote><div><br>Binaries =
in the repository are probably a moot point - either way we need to invest =
some effort into keeping them out. I agree that doesn&#39;t change whether =
we use single or multiple repositories.<br>

<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><di=
v>
&gt; GitHub is a lot more useful as a web-app with single repository in my<=
br>
&gt; experience.<br>
<br>
</div>Can&#39;t you emulate a lot of this by a =93meta=94 project that pull=
s<br>
everything in as a module?</blockquote><div><br>Unfortunately by doing it t=
hat way you lose the ability to properly introspect project history, the ab=
ility to link commits/diffs to issues and other such niceness. <br></div>

<div><br>If I may quote you from last time we had this discussion, &quot;Ha=
ving the diffs and build results functionally linked to tickets/features is=
 more beneficial than whatever vcs is in use in my opinion.
If there is going to be a change then we should try to get a good
_suite_ of tools happening.&quot;<br><br>Having a suite of tools at our dis=
posal is the main factor swaying me towards a monolithic repository.<br><br=
></div></div><br>Shaun<br>

--0015175cd5bc5b5452046c9b5e90--