|
|
ESOE Development |
Hi Shaun,
My experience with other large projects and Git has been the single
What I find does really get painful with the single repository
GitHub is a lot more useful as a web-app with single repository in my
I guess as long as the dependency resolution approach continues and is
regards,
Bradley Beddoes
http://www.intient.com
On 17/06/2009, at 9:23 PM, Shaun Mangelsdorf wrote:
> It's come time again to revisit the idea of using git for
> With the revamped project site, we can now use (almost) any VCS we
> I'd be keen to hear any arguments against git, but in the absence of
> How should the Git repository be structured? I see two options really:
> - One monolithic git repository with a mirror of the current
> Advantages:
> - One git repository per project (broken down per Eclipse project)
> Advantages:
> I'm keen to hear of any more advantages to either approach, or any
> Regards,
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.
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.
experience.
strongly enforced I'd be leaning towards a single approach but it
doesn't concern me either way.
Bradley
Intient Pty Ltd
Twitter - http://twitter.com/bradleybeddoes
Facebook - http://facebook.com/bradleybeddoes
> Hi All,
> 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.
> want. The only feature missing is continuous integration which we
> can address later, outside the scope of this discussion.
> 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:
> structure of the svn trunk
> * 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.
> * More "correct"
> * Easier for other projects to consume our code as submodules
> other thoughts. My preference currently is for one repository, but
> it's certainly not set in stone.
> Shaun Mangelsdorf