Hello, Marcus, I'm afraid you didn't completely understand my proposal - and that is quite understandable because my method might sound crazy until you completely understand it ;-) I'll explain below... Am Donnerstag, 10. November 2011 schrieb Marcus Rueckert:

On 2011-11-08 00:37:09 +0100, Christian Boltz wrote:

...

I know that using svn doesn't change much on _this_ update - but it will save you time on the _next_ updates.

Counter-question: what's the advantage of using the tarball? ;-)

that we can track all local changes, like theme, different auth provider and so on.

Short answer: That works even better if you use SVN checkouts and store everything (including local changes, theme etc.) in another version control system, for example git. Long answer: Let's use a real-world example: the openSUSE wiki uses a modified index.php which at least[1] has this additional line in it: require( $IP . '/extensions/iChainLoginFix.php' ); Now let's update to the latest version of MediaWiki, which is another read-world example ;-) If you use the tarball, you have to - download and extract the tarball - hopefully remember that you added the iChainLoginFix to index.php and do this change on the latest index.php again - if you are unsure if you did other modifications to the upstream code, you have to download and extract the tarball of the old version and to diff against it. Now compare that with using a SVN checkout: - initially run svn co \ http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_17/phase3 - for later updates, just run "svn up" or "svn switch" to update to a new major version - the iChainLoginFix will still be in index.php after svn up or svn switch, except if there is a merge conflict - finding out about local changes is easy - just run "svn diff" In other words: Using a SVN checkout saves time and is much better in handling modified files. This is not a theory, that's experience from a wiki I maintain, and also from the blog software I use. The same works for extensions, at least those that are available via SVN: - installing a new extension: - cd extensions - svn checkout $whatever_extension_you_need - and later: - cd extensions/$extension - svn up (or svn switch) You can also add the bento skin etc. as usual. SVN will flag them with "?" as unknown file/directory in "svn status", but that doesn't hurt. And yes, we now have a wild mix of svn checkouts (MediaWiki core + some extensions) and additional files like the bento theme. But that's still better than having a wild mix of tarballs (MediaWiki core + some extensions) and additional files like the bento theme. ;-) What we have until now will work perfectly if you are working directly in the DocumentRoot on a single server. For the openSUSE wiki, it becomes even more interesting[tm] and confusing because we have more than one server and need a clean deployment method ;-) We could just rsync the DocumentRoot content to all servers. This would work, but lacks version control for the whole picture. Therefore I proudly present the Matryoshka version control system ;-)) Commit everything (including all .svn directories) to another version control system, for example git [2]. You can then a) on the server: deploy from git b) on a development system: run "svn up" in your git checkout and commit the latest MediaWiki/$extension/bento theme/... to git c) on the server: deploy from git again When using tarballs, step b) would be "extract the tarball in your git checkout and commit [...] to git". I hope this mail explains what I mean and wasn't too confusing. If something is not clear, just ask ;-) Regards, Christian Boltz [1] I didn't do a diff against the upstream version and the iChainLoginFix is obviously not upstream code ;-) [2] even CVS would work ;-) The only thing that doesn't work is SVN because you can't store a SVN checkout in another SVN. Well, you could do it with tricks like vendor branches, but you probably don't want to do that because using another version control system is much easier. PS: non-random sig today ;-) -- Was schlagen sie vor, Prof. Dr. cvs. Boltz? :-) [Ratti in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-wiki+owner@opensuse.org