ESOE Development | Google Groups

Re: [esoe-dev] Re: ESOE Project on git?

Shaun Mangelsdorf <s.mangelsd...@gmail.com>

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 to
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 “meta” 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 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."

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

Shaun