Mailinglist Archive: opensuse-wiki (90 mails)
|< Previous||Next >|
Re: [opensuse-wiki] Update to 1.16
- From: "Matthew Ehle" <mehle@xxxxxxxxxx>
- Date: Wed, 22 Sep 2010 14:36:28 -0600
- Message-id: <4C9A146C02000044000860E9@xxxxxxxxxxxxxxxxxxxxxxxxx>
Hello,Christian Boltz <opensuse@xxxxxxxxx> 9/21/2010 12:27 PM >>>
on Dienstag, 21. September 2010, Matthew Ehle wrote:
[...]It seems the inputbox extension lost some modifications I did to
permit bugzilla searches.
Could you tell me where the modified code is, so I can patch the
newest inputbox extension with it?
If you really want, I can take
some time to try a diff, but it could be a bit complicated.
BOFH answer: you are using the wrong version control system for the
OK, I'll have to explain this... ;-)
The easiest way is to use a SVN checkout directly from the
svn.mediawiki.org server (branches/REL1_16/phase3 aka 1.16 branch).
You can then just run a "svn diff" and see what was changed in the local
copy. The same works for the extensions - check them out from
svn.mediawiki.org and later just run a "svn diff".
I'm using this method for the wikis I have on my server  and it makes
maintenance much easier than unpacking tarballs ;-)
A minor update means "svn up", a version update is a "svn switch" to the
branch of the new release. And most important: Both keep my local
changes without any additional work (except if they conflict with
Of course this means that you can't put everything in the openSUSE SVN
because that conflicts with the SVN informations from svn.mediawiki.org.
You could instead use something else (for example git) and check in the
whole SVN tree including the .svn directories.
You can also do some SVN magic with vendor branches.
is a good explanation. But IMHO using another VCS on top of the upstream
SVN tree is easier. (Well, at least if you know both VCS good enough. If
you are a SVN god, vendor branches are the way to go of course ;-)
Hmmm, this is really not a bad idea at all. We would just keep the themes and
custom plugins in berlios and use the MediaWiki SVN for the rest. Can anyone
think of a reason this would not work for our situation? Really, the only core
file we should have to worry about is index.php, and changes on that part of
the file aren't likely.
|< Previous||Next >|