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.
