UpdatingLocalCodebase

From DSpace Wiki

Say you downloaded DSpace 1.2.2, and made a load of modifications. Now you want the features and bug fixes from DSpace 1.3.2, but how do you do that without manually redoing all of the modifications?

Unfortunately there's no magic answer here. There will always be some manual merging involved, but CVS can help out a lot. This page describes how to get CVS to help you. Once you've followed this once, your local code base will be a checkout of the SourceForge CVS tree, which means you can keep up-to-date more easily in the future and over time by doing periodic `cvs update`s.

First, get a checkout of the DSpace you originally started modifying, e.g.:

cvs checkout -r dspace-1_3_1 dspace

Then, copy your modified source code into the checkout. You now have to do a bit of a trick to convince CVS that you haven't actually changed ALL of the files in the tree, since I think it uses dates for that rather than examining the contents of each file. What you can do now is create a patch file that contains the differences between your modified tree and 1.3.1, e.g. with:

cvs diff >my-mods.txt

Now, get a fresh, clean checkout of DSpace 1.3.1 again:

cvs checkout -r dspace-1_3_1 dspace

and apply the `my-mods.txt` patch. Now CVS really knows the changes you made. (By the way: if you added new binary files, e.g. .jars, you'll need to add those again by hand). So, now you can do a `cvs update -r HEAD` which will get CVS to attempt to merge your changes with the differences to the latest code. There are bound to be a few conflicts that you'll have to merge manually, but there's no real way around this. If you wanted to take a more stepwise approach, instead of going straight to HEAD you could try repeating the 'cvs update' with a few intermediate tags (do `cvs log dspace/README` for a list of tags) or dates.

Now that you have a CVS checked-out version of DSpace, it should be much easier to stay up to date with occasional `cvs update`s, though you might want to check that the current CVS code is at least vaguely stable before you do this (ask on dspace-devel).

One more thing -- the above is fine if there's just one of you making some mods to the code, but if you want to have multiple developers working on your code, and/or you need version/release management capabilities, you really need your own CVS tree with the DSpace code on a vendor branch -- see SeparateCvsRepository. Synchronising your CVS tree with the SourceForge one can take a while (resolving conflicts) but there's really no way around that.