On Apr 24, 2012, at 11:25, Ryan Lange wrote:
> 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.
The convention is that /vendor should contain *only* vendor code, with no modifications.
If you want to modify vendor code, copy it elsewhere in your repository and make your modifications (bug fixes, etc.) there. Then, in the projects where you want to use that modified vendor code, you can set an external to that new location.
When a new vendor version is released, you "svn_load_dirs.pl" it in /vendor as usual, then "svn merge" it into your bugfixed/enhanced copy, then update the externals that reference it.
Received on 2012-04-24 18:44:23 CEST