On Jan 17, 2006, at 21:01, Doyle, Patrick wrote:
>> If the vendor project is already in Subversion and your repository
>> and theirs are using the same access method, then I believe you can
>> skip the whole vendor branch thing. If you want to use their project
>> as an external, without modifying their code, you can do that,
>> pointing your svn:external property directly at (a tag, a branch or
>> the trunk of) their repository. If you want to modify their code a
>> bit first,
>
> Yes, this is what I want to do.
>
>> you can initially export a revision of their code and
>> import it into some place in your repository, then merge in changes
>> from their repository as you like. No need to keep your own
>> duplicate in /vendor.
>
> This is where I got completely lost.
Ah, sorry; I'll try to clarify:
> If I export a revision of their code, won't I lose all of the metadata
> associated with their files (such as svn:ignore)?
Yes, that's true, but if you were following the usual vendor branch
methodology, you'd be receiving vendor drops as tarballs and
importing these, and then you wouldn't get any metadata either. It's
not any worse by using their repository directly, I'm saying, and
it's better in that it's easier and less work.
> If I import their code into my repository, isn't that exactly I
> would be
> doing by importing it into /vendor?
Perhaps this is easiest by example. We keep a copy of phpMyAdmin in
our repository—we have PMA deployed on four servers, with
customizations to the configuration file needed for each server, but
also many configuration settings common to all servers, and also
perhaps some local bugfixes that haven't made it into an official
release yet, and maybe our own custom theme. PMA is using CVS, so we
import it into /vendor, following The Book. To start out, we import
PMA 2.7.0-pl2 into /vendor/pma/current and copy it to /vendor/pma/
2.7.0-pl2.
Stuff in /vendor (for example /vendor/pma/current) must not contain
local customizations, however, else they would be lost when you
upgrade to the next version. So if you want to customize, you have to
copy it somewhere else first. We copy /vendor/pma/2.7.0-pl2 to /tools/
common/pma and make our customizations there—add our config file, add
our theme, fix some bugs. I also modified the code to include a
server-specific config file in the parent directory, which doesn't
exist yet. To create a server-specific version, then, I created /
tools/fooserver/pma, created a server-specific config file in there,
and then added an svn:externals property to the directory to bring in
our modified PMA code from /tools/common/pma. Then I can check out /
tools/fooserver/pma on Foo server, /tools/barserver/pma on Bar
server, and so on.
When the PMA team releases 2.7.0-pl3, the upgrade process is as
follows. We use svn_load_dirs.pl to update /vendor/pma/current and
copy it to /vendor/pma/2.7.0-pl3. Now the vendor section is up to
date. Next, we need to update our custom version. That involves
getting a working copy of /tools/pma/common and then doing a merge
from /vendor/pma/2.7.0-pl2 to /vendor/pma/2.7.0-pl3. And then
updating each server's working copy.
If PMA were using Subversion themselves, we could skip all the /
vendor/pma stuff. To start out, we would have exported the 2.7.0-pl2
tag from their repository and imported it at /tools/common/pma. And
to upgrade a working copy of that to 2.7.0-pl3 would simply have been
a merge from their 2.7.0-pl2 tag to their 2.7.0-pl3 tag.
There's probably no reason why your own customizations have to be
outside /vendor; they could just as easily have gone into /vendor/pma/
trunk or /vendor/pma/ours or whatever. I'm not sure what The Book has
to say about this. I just felt it was clearer for our developers to
have a rule "Thou shalt not make customizations in /vendor" and leave
it at that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 18 01:04:35 2006