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.
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.
> 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.
On 18/06/2009, at 10:41 AM, Bradley Beddoes wrote:
> 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.
I prefer smaller repositories.
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.
If a monolithic repository can be avoided, I think that should be the path.
> 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.
> 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?
> 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.
> 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.
What if you need to issue an urgent patch release of spepcppdaemon?
You shouldn't be forced to release all components. Separate issue
though I guess.
Re tooling:
If the tooling works better with a monolithic repository then that is
probably the way to go. It seems strange that redmine can't handle
mutliple source repositories for one project though.
On 18/06/2009, at 6:41 PM, Shaun Mangelsdorf wrote:
> 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.
> If the tooling works better with a monolithic repository then that is > probably the way to go. It seems strange that redmine can't handle > mutliple source repositories for one project though.
After reading this reply, it occurred to me that it's not really unusual to want multiple source repos, so I went digging through the Redmine issue tracker. Somebody has already solved this problem and helpfully uploaded a patch.
From testing this patch, it looks like we'll be able to do everything we need with small repositories. I'll do some more testing of this locally, but assuming it all fits together nicely, small repositories are the way forward.
On 19/06/2009, at 9:37 AM, Shaun Mangelsdorf wrote:
> Re tooling:
> If the tooling works better with a monolithic repository then that is > probably the way to go. It seems strange that redmine can't handle > mutliple source repositories for one project though.
> After reading this reply, it occurred to me that it's not really > unusual to want multiple source repos, so I went digging through the > Redmine issue tracker. Somebody has already solved this problem and > helpfully uploaded a patch.
> From testing this patch, it looks like we'll be able to do > everything we need with small repositories. I'll do some more > testing of this locally, but assuming it all fits together nicely, > small repositories are the way forward.
|
