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
