Re: Nested Subversion Checkout

Olivier Dagenais wrote:
>> I see what you are trying to suggest. I had never thought of it that
>> way. The problem I see with that method is that the other package that
>> gets inserted into the site gets changed as much if not more then the
>> site itself and when it was updated I would have to commit it to the
>> 15 repositories that use that software.
>

> Come to think of it, it looks like the concept of "externals" might be what you were after in the first place: http://svnbook.red-bean.com/en/1.1/ch07s04.html If so, sorry for the added confusion, but at least you'll have more information to make your decision. :)

Yes, externals should work nicely for the common part(s) if you can
arrange them in one or a few subdirectories. Make each site-specific
part a top level project with external references to the common parts.
Then you have your choice about pegging the common code to a tag or
branch for any specific site or letting it float on the trunk to get the
latest. You can probably run a testing site directly from a working
copy - or you can deploy using rsync with the -C option to skip the .svn
subdirectories. It would be best to never edit within the testing
directory even if it is a working copy, though, to ensure that what you
see is what is really committed in the repository.

However, if you are hosting these sites instead of distributing the code
to someone else, I'd suggest trying to push the branding into a database
with the site-specific differences done at runtime in whatever language
you are using rather than maintaining lots of different copies of what
is mostly the same thing.

-- 
   Les Mikesell
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org