Hi All, Just thought you might all be interested to hear the Fedora Commons developers are currently voting on a migration to GitHub for their ongoing repository development. See the recent email to their developers list at:
http://www.mail-archive.com/[email protected]/msg00990.html So far, the Fedora developers seem overwhelmingly in favor of the move (though their vote isn't over yet). It will be interesting to watch as this goes forward, and find out what their experiences are should they switch their development processes to git. - Tim On 11/19/2010 3:43 PM, Peter Dietz wrote: > Hi Hardy, > > Thanks for the question, I'm perfectly happy to share my git knowledge. > > An inspiring read was a blog post about a git branching model. Which > starts out with a pretty intimidating/impressive/informative graphic: > http://nvie.com/posts/a-successful-git-branching-model/ > > Our university has: > - our public facing dspace server: production > - our "do things here first to make sure it doesn't break anything" > server: staging > - our workstations where we do development -- sandbox, sandbox-image, > sandbox-featureB, sandbox-layout > > There is the systems developer (me) who is currently working on > sandbox-image, and another person who's working on sandbox-layout, and > librarians/repo-managers who view code that we check in to the server. > The graphic below shows that all of our baseline features have been in > since *master*. It was generated by gitk --all, a very handy interactive > gui for visualizing what it is your doing. > gitk--all.png > > > From master the code splits to production and staging. > Production splits to make a development line. > The development/sandbox line is split for one that is working on an > image theme, and another that adds other layout changes. > > From the graphic you can see my workflow is not that clean. A better > model would be to have > master > | > production > | > staging > | > / \ > dev-image dev-layout > | > | > image-experiment > > > So when work on dev-layout (our second developer) is finished, I can go > to the staging branch, and merge in work from dev-layout. Deploy to our > staging server and test it. If testing discovers a few bugs, then we > create a new branch from staging, called dev-layout-fix-width, which > developer2 works on and then merge back into staging. If deploying and > testing all passes, then I go to production, and merge in staging, > deploy/test. > > At the same time developer1 works on dev-image, makes a branch called > image-experiment for some really wild code ideas, implementing some > javascript image galleries found on the internet, that we don't like, so > then we can safely delete image-experiment once I've grown tired of it, > and get back to work on dev-image, clean it up, and the fixes go back > upstream like the previous example. > > > I would recommend making yourself a "recipe" book, where you write down > useful commands you've used, and what they do. Then eventually you get a > handy reference sheet of things to help you keep moving along. Its > helpful to not think in terms of in svn I do /this/ ..., but instead to > think to create a new branch and switch to it you type /this/. Which is > probably how people learn human languages as well. > > For the DSpace project, I think it would be nice to eventually migrate > the project to git, but it would be best to understand the workflows in > git, become competent in using it, and to have enough value added to be > worth the effort. One nice thing is that RHEL6 ships git. > > Further reading: > -- http://progit.org/book/ > -- http://git-scm.com/documentation > -- http://help.github.com/ > <http://nvie.com/posts/a-successful-git-branching-model/> > -- > Peter Dietz > Systems Developer/Engineer > Ohio State University Libraries > > > > On Fri, Nov 19, 2010 at 12:46 PM, Pottinger, Hardy J. > <[email protected] <mailto:[email protected]>> wrote: > > Thanks, Peter, that's a really cool overview of your development > process, using GIT! I followed it all the way until the paragraph > staring "Going further" where you start to describe > dev/staging/production/manager processes, and perhaps it's just that > GIT is still totally foreign to me, but it sounds like you have a > process that could be very beneficial to emulate, if you're working > in a multi-developer environment. I wonder if you would be able to > sketch up some diagrams to go with that last part? Also, if you have > any recommendations for further reading on development with GIT, > that would be great. Thanks! > > --Hardy > > > -----Original Message----- > > From: Peter Dietz [mailto:[email protected] <mailto:[email protected]>] > > Sent: Friday, November 19, 2010 11:11 AM > > To: [email protected] > <mailto:[email protected]> > > Subject: Re: [Dspace-tech] JSPUI Customization > > > > Hi, > > > > I used to follow the put everything in > dspace/modules/<webapp-name>/... > > but I found that to be duplicate work, as I would develop the > feature in > > dspace-jspui, then once it was working well, I would copy it to > > dspace/module/jspui, and clean up dspace-jspui. However, if you > have a > > good VCS/SCM (source code version control), then it might work > better to > > keep a "dirty" dspace-source. > > > > Essentially you can leave your changes in dspace-jspui, do > regular mvn > > package, ant update, then when you have to upgrade to 1.7, do > directory > > diff between all of your modifications and the version you > started from > > (1.6.2). Then do a clean checkout of 1.7.0, and apply all of your > > customizations to the 1.7 dspace-jspui code. A little tedious, but > > upgrades are at most once a year, where as development might be > daily. > > > > I don't think this advice/approach is in the DSpace > documentation, but I > > find it to be the best for me. Also for version control I use GIT, so > > that will be what the advice below uses. > > > > My development flow is essentially this: > > > > ## Get a copy of dspace source code from a stable tag. I don't > recommend > > git svn clone ... because thats really slow as it gets the entire > > project history (5+ years), which is useless to you locally. > > svn export http://scm.dspace.org/svn/repo/dspace/tags/dspace-1.6.2/ > > dspace-source > > cd dspace-source > > > > ## Initialize a Git Repository > > git init > > > > ## Ignore the compiled output directories from version control > > echo "target/" >> .gitignore > > > > > > ### Advanced Stuff so that when you clone your git repository > > (check it out to a new directory), that you don't get maven compile > > problems. > > ## Because git only files (and not empty directories), > ensure that > > the webapp directories exist > > mkdir -p dspace/modules/jspui/src/main/webapp > > dspace/modules/lni/src/main/webapp dspace/modules/oai/src/main/webapp > > dspace/modules/solr/src/main/webapp > dspace/modules/sword/src/main/webapp > > dspace/modules/xmlui/src/main/webapp > > > > ## And add dummy files to the webapp directories, so that git > > tracks the webapp folders to exist. > > touch dspace/modules/jspui/src/main/webapp/.gitignore > > dspace/modules/lni/src/main/webapp/.gitignore > > dspace/modules/oai/src/main/webapp/.gitignore > > dspace/modules/solr/src/main/webapp/.gitignore > > dspace/modules/sword/src/main/webapp/.gitignore > > dspace/modules/xmlui/src/main/webapp/.gitignore > > > > > > ## Add all the files to the git repository > > git add . > > > > ## Commit the change > > git commit -a -m "Initial Import of DSpace 1.6.2" > > > > ## Optionally make yourself a tag (i.e. name the commit) so that you > > always know where the clean 1.6.2 was. > > git tag -a DSPACE162 -m "Clean DSpace 1.6.2" > > > > > > > > ### Optional: Go to github.com <http://github.com> (or your > local central git > > repository server) and create a repository. > > ## Add a remote for the central repo, and push your code to it. > > git remote add github [email protected]:myusername/myproject.git > > git push github master > > > > > > > > Thats all the prework to get started doing DSpace development in Git. > > I'll show a little example of how you might do some changes, and > use git > > to track all of that. > > > > Say you want to edit in JSPUI the community-list.jsp and add an > > expand/collapse buttons for the list. We'll start a new development > > branch to do this, edit the file, commit it to the development > branch, > > and then merge it back into master (trunk). > > > > ## Create an appropriately named branch > > ~/dspace-source[master]$ git checkout -b comlist-expand-collapse > > > > ## Edit the file, make your changes to add the functionality you > wanted. > > ~/dspace-source-mine[comlist-expand-collapse]$ vi > dspace-jspui/dspace- > > jspui-webapp/src/main/webapp/community-list.jsp > > > > ## Commit the change. Notice that we're on the > comlist-expand-collapse > > branch > > ~/dspace-source-mine[comlist-expand-collapse*]$ git commit -a -m > "Added > > expand/collapse buttons to the community list" > > [comlist-expand-collapse 0885433] Added expand/collapse buttons > to the > > community list > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > ## Jump back to master > > ~/dspace-source[comlist-expand-collapse]$ git checkout master > > Switched to branch 'master' > > > > ## Merge the changes of the development branch into master > > ~/dspace-source-mine[master]$ git merge comlist-expand-collapse > > Updating 1e73bb7..0885433 > > Fast-forward > > .../src/main/webapp/community-list.jsp | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > ## Push the changes to your central repository > > ~/dspace-source[master]$ git push github master > > > > > > > > > > > > Going further, I use master as the baseline for across-the-board > > features added to production, staging, development. Then new features > > get developed in a developer-1-feature-A, developer-1-feature-B, ... > > branches, which once fixed up gets merged into the staging branch for > > testing, once its tested, verified, and approved it gets merged into > > production and master. > > > > I've also wiped out dspace/config, and made it a git submodule > (similar > > to svn external), in there I have dspace/config branches for > production, > > staging, developer-1, developer-2, ... so that we can all share > the same > > source code improvements, but keep the input-forms, passwords, > database > > names, assetstore locations, webui styles, etc all separate. > > > > Not using dspace/module overlays, and using a single repository > for all > > lines of development definitely adds a bit of complexity, but if > you're > > game for doing things a bit smarter then it adds up to being > worth it. > > > > > > > > -- > > Peter Dietz > > Systems Developer/Engineer > > Ohio State University Libraries > > > > > > > > > > 2010/11/19 Claudia Jürgen <[email protected] > <mailto:[email protected]>> > > > > > > Hello Shaun, > > > > the customizations should be in: > > [dspace-source]/dspace/modules/jspui/src/main/webapp/... > > to be available during build. > > During build these do overlay the defaults. > > > > After having put your customized jsp's there you got to > rebuild and > > redeploy your application. > > > > Hope that helps > > > > Claudia Jürgen > > > > > > Am 19.11.2010 08:13, schrieb Shaun Donovan: > > > > > Hi all. > > > > > > I would like to find out where I should keep my customized jsp > > files > > > (layout/header-default.jsp) so that they are implemented if I > > rebuild > > > the application. The Documentation states: > > > > > > If you wish to modify a particular JSP, place your edited version > > in the > > > [dspace-source]/dspace/modules/jspui/ > > > src/main/webapp/ directory (this is the replacement for the > > > pre-1.5 /jsp/local directory), with the same path as the > > > original. > > > > > > Then they give an example: > > > > > > To edit [jsp.dir]/community-list.jsp, the customized version must > > go > > > in : > > > > > > [jsp.custom-dir]/dspace/modules/jspui/src/main/webapp/community- > > list.jsp > > > > > > What they don't tell me is what [jsp.dir] or [jsp.custom-dir] is > > (are > > > they the source or target directories). > > > > > > I have tried all kinds of variations without success, the default > > files > > > get deployed. > > > > > > So, my source code is in /dspace-src, and my built application > > > is /dspace. > > > > > > Am I supposed to put my customizations in > > > /dspace-src/dspace/modules/jspui/src/main/webapp/dspace- > > src/modules/jspui/src/main/webapp/layout/header-default.jsp > > > > > > I have tried this as well as > > > /dspace- > > > src/dspace/modules/jspui/src/main/webapp/dspace/modules/jspui/src/main/w > > ebapp/layout/header-default.jsp > > > > > > as well as > > > /dspace-src/dspace/modules/jspui/src/main/webapp/layout/header- > > default.jsp > > > > > > but all to no avail. > > > > > > Any help would be greatly appreciated. > > > > > > Shaun. > > > > > > > > > > > > ----------------------------------------------------------------- > > ------------- > > > Beautiful is writing same markup. Internet Explorer 9 supports > > > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& > > L3. > > > Spend less time writing and rewriting code and more time > > creating great > > > experiences on the web. Be a part of the beta today > > > http://p.sf.net/sfu/msIE9-sfdev2dev > > > _______________________________________________ > > > DSpace-tech mailing list > > > [email protected] > <mailto:[email protected]> > > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > > > > -- > > Claudia Juergen > > Universitaetsbibliothek Dortmund > > Eldorado > > 0231/755-4043 > > https://eldorado.tu-dortmund.de/ > > > > > > > ------------------------------------------------------------------- > > ----------- > > Beautiful is writing same markup. Internet Explorer 9 supports > > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM > L2 & L3. > > Spend less time writing and rewriting code and more time > creating > > great > > experiences on the web. Be a part of the beta today > > http://p.sf.net/sfu/msIE9-sfdev2dev > > _______________________________________________ > > DSpace-tech mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > > > > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > > > > _______________________________________________ > DSpace-tech mailing list > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
