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
Received on 2010-10-15 00:09:07 CEST