My concern with Git, is how much history do we want to retain?
If you import the entire dspace timeline of commits since 2002, you create a git repository that is well over 500MB, that each instance / developer has checked out. Git, however is still fast at branching, committing, adding, etc. Perhaps there would be a point after a major restructuring in the DSpace history that could be a better start to history.
I don't see the problem that Git will create a horde of core-hackers. If dspace-api doesn't do what an end-developer needs it to do, then they have no choice but to touch it. The good news is that this might put pressure on refactoring dspace-api, so that an end-developer doesn't need to touch it to make DSpace do what they want. Those who still modify their dspace-api will likely have new features that are worth sharing then. I don't think warning signs of saying to not modify dspace-api will work, not if the alternative is an eleventeen step process that still doesn't work as well as just modifying dspace-api.
Git doesn't kill all of the modules, sandboxes, etc. We would likely have a project called dspace1, which has trunk/master and all of the numbered branches and tags. Everyone who needs a sandbox account can clone dspace/dspace1, name their project peterdietz/dspace1-plus-versioning which is hosted on their github account. After they make massive improvements, everyone tests their code, and it possibly gets pulled back into dspace/dspace1 master. A university could clone the tag dspace/dspace1:dspace-1.7.0 to MITlibraries/dspace1, which has their UI customizations and new features.
On Wed, Nov 24, 2010 at 4:50 PM, Mark H. Wood <email@example.com>
There *is* need to provide some structure around a distributed SCM.
Git, for example, was developed to manage the evolution of the Linux
kernel, which is huge and regularly worked on by dozens or perhaps
hundreds. We'd do well to study how it's used in that context. It's
not a free-for-all, though it is open to all.
A case study of an organization that switched a large project to DSCM would be useful. Due to the migration cost, I've seen groups change development of their 2.0 line to DSCM, keeping 1.x in SVN but mirrored to DSCM. My approach is that I use svn to make dspace/duraspace commits, and git for my local institutions repository.
Smaller / agile / newer projects, based on ruby or php seemed to jump ship and magically appear all over github. That may be my imagination.
Ohio State University Libraries