Hello, I hope this is appropriate for the mailing list—and I apologize if it isn't—but I have a repository design issue that I haven't been able to find discussed elsewhere and was wondering if anyone would be willing to offer their thoughts.
I'm using a single repository to hold multiple projects. Each of these projects uses third party code from a particular vendor. They may use different versions of that code, but this is handled well using vendor branches as described in the SVN book, with a slight twist to accomodate multiple projects. - / (repository root) - projects/ - ProjectA/ - VendorA/ (svn:externals "^/vendors/VendorA/1.1/") - ProjectB/ - VendorA/ (svn:externals "^/vendors/VendorA/1.0/") - vendors/ - VendorA/ - 1.0/ - 1.1/ - current/ I've so far had no need for project-specific customizations, which is why I'm using svn:externals. Now, I also maintain a couple of local bug fixes for VendorA's code. Since they're bug fixes, they should be available to all projects. The part I'm struggling with is just figuring out the cleanest way of handling this situation. My first thought was to load up the initial drop, patch it, and tag it in some way indicating that it has been customized. Something like this: - vendors/ - VendorA/ - 1.0-custom1/ - current/ Then I realized that svn_load_dirs (or Ubuntu's equivalent, at least: svn-load) doesn't actually merge changes; it's just an import. That means any customizations in "current" would be overwritten and I would have to reapply my patches for each new vendor drop. Another option is to keep the customizations separate: - vendors/ - VendorA/ - 1.0/ - current/ - vendors-custom/ - VendorA/ - 1.0-custom1/ - current/ Maybe a combination of the two: - vendors/ - VendorA/ - 1.0/ - 1.0-custom1/ - current/ - current-custom/ But with the extra merging and tagging that would be needed to keep this custom branch up-to-date, it might actually be easier to just re-patch each new vendor drop. Any thoughts, advice, and suggestions would be very welcome. Thanks, Ryan