On Fri, 15 Oct 2010 00:08:28 +0200, Stefan Sperling wrote:
> On Thu, Oct 14, 2010 at 09:17:59PM +0000, Dan Nessett wrote:
>> 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?
>
> Unfortunately, this won't work. You cannot use externals like this. The
> existing files are in the way.
>
> But I may be wrong, or maybe I misunderstand your idea. In general, with
> a complex tool like Subversion the best way to see if something will
> work is to just try it out and see.
>
>> If so, are there some reasons why it isn't a good idea.
>
> There's nothing wrong with your idea itself. But Subversion doesn't
> support an "overlay" concept like you want to realise with externals.
>
> Also, I'd recommend not using file externals for anything, because their
> implementation is a hack and there are several known issues:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3351
> http://subversion.tigris.org/issues/show_bug.cgi?id=3589
> http://subversion.tigris.org/issues/show_bug.cgi?id=3665
> http://subversion.tigris.org/issues/show_bug.cgi?id=3563 Directory
> externals are fine though.
>
> The problem you're trying to solve (vendor branching) isn't easy, and
> many have tried before and devised solutions. So I'd suggest that before
> trying to devise schemes of your own, shop around for existing
> solutions. One of them will probably fit the bill.
>
> The existing alternatives I know about are:
>
> - Subversion's vendor branching with svn_load_dirs.
> This works fine in general, but handling of renamed files is a bit
> clunky. It's what the svnbook describes.
>
> - Play with Subversion's foreign repository merges.
> This is a little-known feature that could help you track the
> MediaWiki changes, as long as MediaWiki keeps using Subversion. See
> http://blogs.open.collab.net/svn/2008/03/do-not-post-mer.html (which
> was written before the 1.5 release but is still relevant). You'd do
> something like this in the working copy of your custom MW code:
> svn merge \
> http://svn.wikimedia.org/svnroot/mediawiki/trunk/@74770 \
> http://svn.wikimedia.org/svnroot/mediawiki/trunk/@74798
>
> - Try Piston. I've never tried it myself, but its interface seems nice
> and I've seen it being recommended on this list before. The
> dependency on Ruby isn't nice but quite possibly worth it.
>
> Good luck,
> Stefan
Thanks. Your description of alternative approaches was very helpful.
Regards,
--
-- Dan Nessett
Received on 2010-10-15 02:02:16 CEST