Hey, all.
In the past my git-based DSpace workflow was this: our DSpace git
repository had 'development' and 'production' branches, and I maintained
two config files, dev_dspace.cfg and prod_dspace.cfg. When redeploying
my web apps I simply specified which config I want to use, for example:
sudo ant -Dconfig=../../prod_dspace.cfg update
This made it easy to maintain one code base for different environments,
as well as keeping our configuration changes out of git; keeping our
changes outside of dspace.cfg makes it easier to merge patches from
DSpace master, as well as have less headaches between dev/prod environments.
With DSpace 1.8 the main DSpace config file has been split into several
subsections and my workflow is now broken. Not only do my changes
diverge from upstream, I can't maintain dev/prod configs in one code
base. I could commit my config changes to git, but then I'd have to
worry about passwords and other internal information getting into our
public github. I could maintain two separate git checkouts, but that
seems like a waste. Trying to establish the path of least resistance,
some sort of a balance between ease of use and git-admin fu. :)
How are other people handling this?
--
Alan Orth
alan.o...@gmail.com
http://alaninkenya.org
http://mjanja.co.ke
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out how
to use my telephone." -Bjarne Stroustrup, inventor of C++
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
