views:

221

answers:

3

I have been using an open source Java project and had to make some custom changes for our site. I have downloaded the source code via Subversion, modified two files and built a custom JAR file. Now I need to store these custom changes into OUR Subversion source control system. What is the best way to do this?

Should I check the entire tagged version of the open source code into our system and then create a branch with our change in it? Or should I just check-in our custom files and rely on the open source tagged version to always be around? Or perhaps something else altogether?

A: 

The Subversion book is free and available online, with a section devoted to choosing a repository layout.

the Subversion community recommends that you choose a repository location for each project root—the “topmost” directory that contains data related to that project—and then create three subdirectories beneath that root: trunk, meaning the directory under which the main project development occurs; branches, which is a directory in which to create various named branches of the main development line; and tags, which is a collection of tree snapshots that are created, and perhaps destroyed, but never changed.

I'm happy to elaborate if you are having trouble determining what exactly this means for your project.

Matthew Vines
+5  A: 

Take a good look at Subversion vendor branches, which are meant for "maintain[ing] custom modifications to third-party data in your own version control system". This sounds like exactly what you want. You would create a vendor branch for the open source Java project in your main repo (from their last SVN revision before your modifications). Then, check in your modifications. In the future, you can merge in upstream changes.

Matthew Flaschen
+1 I think you understood what was being asked better than I did. I assumed it was a more general query about how to set up the repository.
Matthew Vines
A: 

First try to avoid this as long as you can, if it is possible try to get your changes into the open-source project (less work for your self in the future...)

But if that was not a option, I would follow Matthew Flaschen advice about vendor branches.

Johan