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)
- VendorA/ (svn:externals "^/vendors/VendorA/1.1/")
- VendorA/ (svn:externals "^/vendors/VendorA/1.0/")
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:
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:
Maybe a combination of the two:
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.
Received on 2012-04-24 18:25:56 CEST