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
