On Thu, 14 Oct 2010 21:17:59 +0000, Dan Nessett wrote:
> 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.
Bad etiquette to answer my own question, but I just reread the Externals
Definition section of the book and found this:
"An externals definition can point only to directories, not to files."
So, what I have described won't work even if overloading with
svn:externals is supported.
--
-- Dan Nessett
Received on 2010-10-14 23:49:15 CEST