From DSpace Wiki

What if you have a team that wants to collaborate on a DSpace modification? You can all check the code out of Source``Forge CVS anonymously and pass patches around, but this will get very complicated (and probably produce errors) very quickly. What you really need is your own CVS repository. This is also useful for managing any minor customisations your organisation has made to DSpace. This page describes the basics of how to:

• Import the DSpace code into a second CVS repository
• Update the DSpace code in your repository to the latest DSpace version, without overwriting your changes

The example below assumes you want to start working with DSpace version 1.2.2, make some mods, and then at a later date update your modded DSpace to version 1.3. For other versions all you need to do is replace the tags with the relevant version tag. TODO: How make patches from your local mods in CVS to contribute to DSpace core TableOfContents

Import the DSpace code into a local CVS repository

Grab appropriate version of DSpace from Source``Forge. e.g.:

cvs -d:pserver:anonymous@dspace.cvs.sourceforge.net:/cvsroot/dspace export -r dspace-1_2_2 dspace

Note that you could use a downloaded .tar.gz package, but getting straight from CVS will also get you useful .cvsignore files and a script to bundle a .tar.gz package that you can use to easily publish/deploy yourself. Set CVSOOT to your own CVS repository. Then import the sources onto a named vendor branch in your CVS repository.

cd dspace
cvs import -I ! -m "Import DSpace 1.2.2" dspace SourceForge dspace-1_2_2

• `-I !` is to make sure that the 'core' directory is imported (it's on CVS's default ignore list).
• `"Import DSpace 1.2.2"` -- log message
• `dspace` -- the name for your DSpace module in CVS
• `SourceForge` -- vendor tag. You will need to specify this exactly later on, so choose carefully.
• `dspace-1_2_2` -- a symbolic tag for the raw DSpace release in your CVS repository. It's up to you what this is but keeping it consistent with Source``Forge CVS is probably a wise idea.

Now you can scrap the directory you're in. efore working on the code, do a CVS checkout from your own CVS repository. Edit as normal, check things back in as you please.

To update your modified DSpace code

Probably best to make sure everyone's checked in all of their mods before doing this, and ask everyone not to touch CVS while you're doing it! Export the new version of DSpace from the SourceForge repository, e.g. with:

cvs -d:pserver:anonymous@dspace.cvs.sourceforge.net:/cvsroot/dspace export -r dspace-1_3 dspace

Import this into your local CVS repository, taking care to use the same vendor tag as before (`SourceForge` in this example). ecommend you add a `-n` flag right after `cvs` to do a dry run before doing it for real!

cd dspace
cvs import -I ! -m "Upgrade to 1.3" dspace SourceForge dspace-1_3

You should see something along the lines of:

U dspace/.cvsignore
U dspace/CHANGES
U dspace/KNOWN_UGS
U dspace/LICENSE

... ...

U dspace/src/org/dspace/storage/rdbms/TableowIterator.java
U dspace/src/org/dspace/storage/rdbms/package.html
cvs import: Importing /home/localcvs/dspace/src/org/dspace/workflow
U dspace/src/org/dspace/workflow/WorkflowItem.java
U dspace/src/org/dspace/workflow/WorkflowManager.java
U dspace/src/org/dspace/workflow/package.html
6 conflicts created by this import.
Use the following command to help the merge:
cvs checkout -j<prev_rel_tag> -jdspace-1_3 dspace

Now, get a fresh checkout from your local CVS repo, and, with CVSOOT set to your own repo, do (again, recommend adding `-n` as a dry-run first):

cvs update -j dspace-1_2_2 -j dspace-1_3 dspace

You should see messages like:

cvs update: Updating dspace/src/org/dspace/search
dspace/src/org/dspace/search/DSAnalyzer.java already contains the differences between 1.1.1.1 and 1.1.1.2
CS file: /home/localcvs/dspace/src/org/dspace/search/DSIndexer.java,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.2
Merging differences between 1.1.1.1 and 1.1.1.2 into DSIndexer.java
rcsmerge: warning: conflicts during merge

Now comes the tricky part: you need to resolve any conflicts between your modifications and the 1.3 upgrade. To list the files which need attention:

cvs -n -q update dspace

Results should look like:

C dspace/config/dspace.cfg
dspace/jsp/components/news.jsp
dspace/jsp/dspace-admin/confirm-delete-eperson.jsp
dspace/jsp/dspace-admin/list-communities.jsp
...
dspace/jsp/image/submit/verify-done.gif
dspace/jsp/image/submit/verify-notdone.gif
C dspace/lib/EADME
C dspace/src/org/dspace/app/webui/jsptag/ItemTag.java
C dspace/src/org/dspace/handle/HandleManager.java
C dspace/src/org/dspace/search/DSIndexer.java
C dspace/src/org/dspace/search/DSQuery.java

• `C` -- conflicts during merge. These are the files where you'll have to go in by hand and fix any problems.
• `` -- file was removed (or moved) between DSpace versions. You can just remove this Note: Not sure what happens if you'd modified this file -- RobertTansley

Go in, fix the files marked `C`, test, check the changes back in, and (after some more testing) you're done.

If you've already made modifications

If you already have a customised DSpace, but don't have it in a CVS repo yet, it's not too hard to fit this retroactively. First thing to do is follow the "Import the DSpace code into a local CVS repository" instructions for the version of DSpace on which your customisations are based. (If you're using Source``Forge CVS HEAD, probably best to use the current date in case SF CVS is updated while you're doing all this.) Then, once you checked out DSpace from your own repo, copy over your changes to this checkout. If you've made large changes and can't remember what you've changed, just copy the whole tree over, but make sure all the paths and filenames match, and don't delete the .cvsignore files. Then you should just be able to check in the changes to CVS and follow the update process when the time comes.