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 protected]> wrote:
> 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.
You can take a peek at mediashelf: https://github.com/mediashelf/
--
Peter Dietz
Systems Developer/Engineer
Ohio State University Libraries
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
