On Tue, Jun 12, 2012 at 10:02 AM, Kirti Bodhmage <k.bodhm...@qmul.ac.uk> wrote: > I meant subversion code control at my University. > I want to keep my live code in my local subversion repository so that I can > keep track of changes and development in Dspace code. > > Dspace out of box means Dspace without much customisation. > Hope this will clarify my previous email.
OK, thanks for clarification. First, I really recommend you to try Git instead of Subversion, because DSpace recently moved to Git and is hosted at GitHub. Git allows you to work with branches significantly more easily. You don't have to publish your changes on GitHub, a local repository would work just fine. I'll describe workflows I'd use in both Git and SVN, maybe you'll see that in Git you can keep things separated more cleanly and merge more often because Git helps you with that. Subversion: 1) Check out the source code corresponding to the exact version that you're already running and commit that. 2) Commit your patches on top of that. You'll be able to do "svn diff" between the first revision and any later revision with local modifications. Moving to a new version: 3) Do a svn diff between the first and last revision, which will yield all local modifications. 4) Get the new version from dspace.org or Github and commit it _without your local changes_. 5) Apply the patch with you modifications, resolve any conflicts (this can get hairy). Git: 1) Clone the repository and switch to a branch corresponding to the exact version that you're already running. 2) Create a separate branch (let's call it "local" here) and always commit your local customizations there. You can always do "git diff" between these two branches to see your modifications. (I also recommend creating a separate branch for the "config" directory and after you commit to the "local" branch, check out its code to this branch, copy your "config" directory over it and commit into this "config" branch. Watch out for any new parameters added to the config files using git diff on the "origin" or "local" branch.) Moving to a new version: 3) You can pull changes to the branch you're running as often as you want (usually after minor releases) and merge the changes into your "local" branch. This will often be a "fast-forward" merge (depending on whether you decide to keep the "config" directory in the same branch). These workflows are just one possibility and they are what I would use. Hope that helps. Regards, ~~helix84 ------------------------------------------------------------------------------ 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
