On Thu, 14 Oct 2010 21:55:08 +0200, Olivier Sannier wrote:
> 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.
I just reread the Vendor drop section in the book. It doesn't actually
address the question I raised (which is about overloading files obtained
with the svn:external definition). We don't do exactly what is described
in the book, but logically it is the same. Instead of importing the
vendor drop into the repository, we import it into a workspace (manually
by checking it out and then recursively deleting the .svn directories.
Perhaps we should use the svn import command, but that is a side issue).
We then do the merge in the workspace and commit to a new version in the
repository.
My question has to do with bypassing the fetch of the complete new MW
version into our repository. (NB: MW revisions run about 150MB). Let me
describe this in more detail.
+ When we wish to upgrade to a new MW revision, check out the directory
in *our* repository that contains our modified files (and only those
files).
+ Merge each of these files with those in the new MW revision. (NB: there
are only a very few of these).
+ After resolving any conflicts, commit these changes into a new revision
in *our* repository, probably tagging it so it is easy to reference.
+ svn mkdir to create an empty workspace.
+ With svn propedit add an svn:externals property to this directory so
that the whole source effectively is an external fetch of the appropriate
MW revision.
+ With svn propedit add lines to the svn:externals definition in the top-
level directory that describe the files we just merged, instructing
subversion to get these from the new branch we just created in *our*
repository. (Note: this is where the "overload" occurs, since files with
the same name and at the same location in the MW repository revision
exist. We don't want fetch these - we want a checkout to get the merged
files from *our* repository instead.)
+ Commit this to *our* repository under a new tag.
Will this work? If so, are there some reasons why it isn't a good idea.
--
-- Dan Nessett
Received on 2010-10-14 23:18:45 CEST