Quick note here: from the tone of some of these emails, it seems like we've suddenly jumped from "look how others are using Git" to "DSpace should move to Git/GitHub".
My previous email about Fedora Developers voting on whether or not to move to using GitHub should not be seen as a recommendation that DSpace also should move that way. I was just trying to make everyone aware of a discussion about Git going on with the Fedora developers. That being said, it's perfectly fine for this discussion to take place about pros/cons of Git/GitHub for DSpace development. However, I'd encourage this discussion to move over to 'dspace-devel', as it's a more appropriate location -- others are free to join the discussion over there. Just want to put this all back in context. :) Personally, I'm just interested in seeing whether Fedora makes the switch (seems like the vote is still heavily in favor) and what their experiences look like. We can still continue to brainstorm out whether or not it would be worthwhile for DSpace. Right now, I'm personally not sure. It seems like an interesting idea, but it would obviously require much more discussion/analysis before making any decisions. There's no reason to make such a "jump" unless the majority of us are on the same page, and feel there are real benefits (and no large disadvantages). In the meantime, individual developers are obviously welcome to pull DSpace code into GitHub for their own purposes, or just to play around (I may actually try that out one of these days myself). After 1.7.0 is out the door, we could always schedule a Special Topic meeting to discuss Git/GitHub in more detail, if we felt we wanted to. Feel free to continue discussion -- just wanted to recommend it move to dspace-devel as we dig deeper. - Tim On 11/30/2010 11:39 AM, Peter Dietz wrote: > 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 <mw...@iupui.edu > <mailto:mw...@iupui.edu>> 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 > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
