vendor branch and externals on local projects

[Anthony Ettinger <an...@chovy.com>]

I found myself in a precarious situation formulating a re-usable
vendor branch strategy supporting localized modifications.

This is how my svn structure is now:

./vendor/package1/current (always the current release I am using)
./vendor/package1/1.0
./vendor/package1/2.0

This is pretty straight forward using svn-load-dirs.pl

Now, I also want to customize this, so I added a customization layer
that will be merged from ./vendor/package1/LatestX.x and
./vendor/package1/current into:
./customizations/vendor/package1/

This is where I will add my modifications that all other projects will use.

Now...the last step is all the projects that use this customization
layer are simply using an svn:externals rule to update...makes it
really easy from the project side of things.

./project1/package1 (svn:externals rule using ./customizations/package1)

The problem is I do have to make some changes at the project level,
ie: removing an installation file, or modifying the configuration file
for the package.
This results in things like:

$ svn st
X      htdocs

Performing status on external item at 'htdocs'
?      htdocs/include/config.php
!      htdocs/install/index.php

If I checkin the config.php or remove the index.php from svn, the
change will be passed back up the chain to the
./cusomizations/vendor/package1 source, which I do NOT want to do.

Short of simply ignoring these local changes, is there any other way
to do this without having to do localized merges between
./customizations on each ./project area?

-- 
Anthony Ettinger
408-656-2473
http://anthony.ettinger.name

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org