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