Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion ESOE Project on git?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Shaun Mangelsdorf  
View profile  
 More options Jun 18, 6:41 pm
From: Shaun Mangelsdorf <s.mangelsd...@gmail.com>
Date: Thu, 18 Jun 2009 18:41:05 +1000
Local: Thurs, Jun 18 2009 6:41 pm
Subject: Re: [esoe-dev] Re: ESOE Project on git?

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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google