On 14/10/2010 21:45, Dan Nessett wrote:
> On Thu, 14 Oct 2010 15:38:41 -0400, Bob Archer wrote:
>
>>> I develop for a site that uses Mediawiki (MW). We make some
>>> modifications to it before deployment. Generally, (using subversion) we
>>> check out a tagged version into a workspace, recursively delete the
>>> .svn directories, modify a small number of files, add some of our own
>>> extensions, and then commit the result into our own repository. We then
>>> work with the source from there.
>>>
>>> This approach means we have to track MW bug-fixes and add them to our
>>> modified version. I was wondering if there is a better way to
>>> accomplish the same objective. For example, we can use the
>>> svn:externals property to point to the MW repository version of the
>>> extensions we use, so each time they are updated, all we need to do is
>>> svn up on the externals directory.
>>>
>>> The main source is a different story. Since we modify some of the files
>>> (and have no commit privileges to the MW repository), the files we
>>> modify are not within our purview to change (and understandably the MW
>>> people wouldn't allow it even if we had commit privileges).
>>>
>>> Is there any way to use the svn:externals property to solve the main
>>> source issue? For example, could we point the revision we keep in our
>>> main repository to the correct revision in the MW repository and then
>>> tag the appropriate directories that contain the files we modify with
>>> svn:external. These latter svn:external properties would name the
>>> individual files we modify and point to the modified version that we
>>> could keep in our repository. My concern is we are "overloading" the
>>> files in the MW repository with files in our repository and I am not
>>> sure subversion allows that.
>>>
>>>
>> There is a whole section in the svn book about this...
>>
>> http://svnbook.red-bean.com/nightly/en/svn-
> book.html#svn.advanced.vendorbr
>> BOb
> I have read this section. It is about vendor drops, but it doesn't answer
> the question I asked. Basically, we are doing a vendor drop now.
>
> Dan
It actually does, but it's a bit hard to understand. Reread it carefully
and you'll see that you actually track the public changes in a branch
that you later merge back into your trunk.
Received on 2010-10-14 21:55:53 CEST