|
|
ESOE Development |
On 18/06/2009, at 10:41 AM, Bradley Beddoes wrote: This does cause issues with branching/tagging etc, but it may be a If a monolithic repository can be avoided, I think that should be the > What I find does really get painful with the single repository For example, the Grails plugin does have binaries in svn. > GitHub is a lot more useful as a web-app with single repository in my
> My experience with other large projects and Git has been the single I prefer smaller repositories.
> repository approach with top level directories for each sub component.
> I've used a couple that have gone the other way. Overall there are
> positives and negatives to both.
good opportunity to investigate whether all of the modules need to be
bound to the same version number and release cycle.
path.
This is painful even with multiple. But at least with multiple you can
> 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.
isolate the pain.
Unfortunately this is really unavoidable. If it was it's own repo it
wouldn't be infecting the whole project.
Can't you emulate a lot of this by a “meta” project that pulls
> experience.
everything in as a module?
> I guess as long as the dependency resolution approach continues and is What's that? You want to use Maven? :P
> strongly enforced I'd be leaning towards a single approach but it
> doesn't concern me either way.