Question

I use a script for my homepage but I’d like to localize it. Furthermore the CSS uses images from a special folder which does not fit to my folder hierarchy.
Because I don’t want to adopt these paths and settings I’ll have to modify the original sources.

Currently my repository looks like this:

• /3rdParty
• /CompanyA
• /CompanyAProduct1
• /v1_0
• /v1_1
• /MyProductA
• /branches
• /tags
• /trunk
• /import
• /export
• /source

Via svn:externals I map all stuff I need (lib, dll, or code) into the import folder. Now I’d like to modify the files in the import folder but this will modify the original sources, too (as far as I know).
What is the best solution to have the modified version in my import folder but the original sources remain unaffected? Should I make a branch of the 3rd party code? But then I have to update the original sources for every new release.

Answer 1

Read the section Vendor Branches of the Subversion Redbook (Version Control with Subversion):

http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

General Vendor Branch Management Procedure
Managing vendor branches generally works like this: first, you create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third-party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (e.g., /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking, you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes. … (See the rest of Vendor Branches chapter of the redbook chapter for the specific commands and a full example.)

Basically you check in the vendor code separate from your project, tag the version, and then svn copy it into your project. This will allow you to make your local modifications while still preserving a pointer to the original release version.

The advantage is that when the vendor releases a new version of their product, the redbook delineates how to incorporate the new version into your project so that the same local changes that you had made to the original version are applied to the new version. It is, of course, sound in theory, but may have some gotchas in practice:

But things aren’t always that simple, and in fact it is quite common for source files to get moved around between releases of software. This complicates the process of ensuring that our modifications are still valid for the new version of code, and things can quickly degrade into a situation where we have to manually re-create our customizations in the new version.