ESOE Project on git? - ESOE Development

Message from discussion ESOE Project on git?
Received-SPF: pass (google.com: domain of bedd...@intient.com designates 209.85.222.200 as permitted sender) client-ip=209.85.222.200;
Message-Id: <9C5E4D8B-FA0E-4CEF-8782-16C1D6477969@intient.com>
From: Bradley Beddoes <bedd...@intient.com>
To: esoe-dev@googlegroups.com
In-Reply-To: <90ad28f40906170423m7dc5fca1k28977c08306056a5@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [esoe-dev] ESOE Project on git?
Date: Thu, 18 Jun 2009 10:41:24 +1000
References: <90ad28f40906170423m7dc5fca1k28977c08306056a5@mail.gmail.com>

Hi Shaun,

My experience with other large projects and Git has been the single  
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.

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.

GitHub is a lot more useful as a web-app with single repository in my  
experience.

I guess as long as the dependency resolution approach continues and is  
strongly enforced I'd be leaning towards a single approach but it  
doesn't concern me either way.

regards,
Bradley


Bradley Beddoes
Intient Pty Ltd

http://www.intient.com
Twitter - http://twitter.com/bradleybeddoes
Facebook - http://facebook.com/bradleybeddoes


On 17/06/2009, at 9:23 PM, Shaun Mangelsdorf wrote:

> Hi All,
>
> It's come time again to revisit the idea of using git for  
> development of the ESOE project. A few things have changed since  
> this was last discussed, not the least of which is the transition to  
> Redmine (http://www.redmine.org) for managing the project.
>
> With the revamped project site, we can now use (almost) any VCS we  
> want. The only feature missing is continuous integration which we  
> can address later, outside the scope of this discussion.
>
> I'd be keen to hear any arguments against git, but in the absence of  
> any strong opposition I would say the move to git is inevitable. I  
> believe that tool support is now solid enough that we can make the  
> transition smoothly. There is one main question I put out to the  
> esoe-dev list:
>
> How should the Git repository be structured? I see two options really:
>
> - One monolithic git repository with a mirror of the current  
> structure of the svn trunk
>
> Advantages:
> * Atomic branching and tagging, treating all the code as a unit.
> * Only one history timeline to manage.
> * Repository introspection will continue to function properly -  
> Redmine can only properly link one source repository with a project.
>
> - One git repository per project (broken down per Eclipse project)
>
> Advantages:
> * More "correct"
> * Easier for other projects to consume our code as submodules
>
> I'm keen to hear of any more advantages to either approach, or any  
> other thoughts. My preference currently is for one repository, but  
> it's certainly not set in stone.
>
>
> Regards,
> Shaun Mangelsdorf
>
> >