If you develop MediaWiki core, or work on extensions that the Wikimedia Foundation deploys, you should prepare for your development workflow to switch on the weekend of March 3rd. Instead of Subversion and the Code Review tool at mediawiki.org, we will be using Git and Gerrit.
Summary: https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-subv...
Affected projects: https://www.mediawiki.org/wiki/Git/Conversion#Affected_development_projects
If you work on an extension that the Wikimedia Foundation does not use, or on a non-MediaWiki project hosted at svn.wikimedia.org, you have more time to decide. Talk it over with your community and decide whether you would like to move to Git immediately, move to Git sometime over the next several months, or move to another hosting provider sometime before mid-2013. We would like to gradually migrate all projects currently on Wikimedia's Subversion repository so that we can make all of svn.wikimedia.org read-only by the middle of 2013, and thus only have to support one source control infrastructure.
New workflow instructions, open issues, docs, etc.: https://www.mediawiki.org/wiki/Git
Thank you. (Please feel free to forward this to affected communities.)
Folks, the switchover documentation is all aimed at savvy read-write developers. We drones who just use SVN as a simple yet risky way to keep our live version of MediaWiki fresh need instructions on how to:
* install git (OK, apt-get install git etc.)
* convert our maintenance scripts to use git commands instead of svn commands. In particular for me
svn update
svn status
for i in RELEASE-NOTES-* do echo $i diff: svn diff -r ${BASE-BASE}:HEAD $i|wdiff -d -3|tee /tmp/mediawikiDiff$$ done
Add notes also on how we first cd(1) to the right directory, run some command that zaps all the hidden .svn files and another command that adds all the equivalent hidden .git files or whatever.
On Wed, Feb 15, 2012 at 8:09 PM, jidanni@jidanni.org wrote:
Folks, the switchover documentation is all aimed at savvy read-write developers. We drones who just use SVN as a simple yet risky way to keep our live version of MediaWiki fresh need instructions on how to:
- install git (OK, apt-get install git etc.)
Actually the package is git-core.
- convert our maintenance scripts to use git commands instead of svn
commands. In particular for me
svn update
`git pull origin master`
svn status
`git status`
for i in RELEASE-NOTES-* do echo $i diff: svn diff -r ${BASE-BASE}:HEAD $i|wdiff -d -3|tee /tmp/mediawikiDiff$$ done
We can't possibly write instructions for every obscure shell script somebody might've come up with. For this one I'd suggest taking a look at `git help diff` to get an idea of how git diffs work.
Add notes also on how we first cd(1) to the right directory, run some command that zaps all the hidden .svn files and another command that adds all the equivalent hidden .git files or whatever.
The .git folders will exist after you clone the repository. There won't be any .svn directories there to clean up.
-Chad
On Wed, Feb 15, 2012 at 20:17, Chad innocentkiller@gmail.com wrote:
The .git folders will exist after you clone the repository. There won't be any .svn directories there to clean up.
.git folder (singular).
Subversion puts .svn in nested subdirectories, git doesn't. There's only one .git and it's in the root of the repo working dir. (unless you're using a bare repo)
So, you can remove with just `rm -rf path/to/git/repo/.git`.
-Jeremy
On Wed, Feb 15, 2012 at 8:28 PM, Jeremy Baron jeremy@tuxmachine.com wrote:
On Wed, Feb 15, 2012 at 20:17, Chad innocentkiller@gmail.com wrote:
The .git folders will exist after you clone the repository. There won't be any .svn directories there to clean up.
.git folder (singular).
Subversion puts .svn in nested subdirectories, git doesn't. There's only one .git and it's in the root of the repo working dir. (unless you're using a bare repo)
So, you can remove with just `rm -rf path/to/git/repo/.git`.
Yeah, I changed the plural in that sentence like 3 times. Thanks for correcting me.
-Chad
On 16 February 2012 02:28, Jeremy Baron jeremy@tuxmachine.com wrote:
Subversion puts .svn in nested subdirectories, git doesn't.
Not anymore. Since Subversion 1.7, there is only one .svn directory in the root of the working copy.
-- [[cs:User:Mormegil | Petr Kadlec]]
On Wed, 15 Feb 2012 23:54:29 -0800, Petr Kadlec petr.kadlec@gmail.com wrote:
On 16 February 2012 02:28, Jeremy Baron jeremy@tuxmachine.com wrote:
Subversion puts .svn in nested subdirectories, git doesn't.
Not anymore. Since Subversion 1.7, there is only one .svn directory in the root of the working copy.
-- [[cs:User:Mormegil | Petr Kadlec]]
Of course no-one uses 1.7 ;)
On Wed, 15 Feb 2012 17:17:28 -0800, Chad innocentkiller@gmail.com wrote:
On Wed, Feb 15, 2012 at 8:09 PM, jidanni@jidanni.org wrote:
Add notes also on how we first cd(1) to the right directory, run some command that zaps all the hidden .svn files and another command that adds all the equivalent hidden .git files or whatever.
The .git folders will exist after you clone the repository. There won't be any .svn directories there to clean up.
-Chad
;) Actually you mean "folder", not "folders" (well, unless you're talking about subfolders within .git/). Unlike .svn with its complete mess, you don't need something fancy to clean it up. Since git uses nothing but one root .git/ folder.
Though double checking. It looks like rather than asking how to clone the git repo. He's asking how to convert a svn based checkout to a git checkout.
"DF" == Daniel Friesen lists@nadir-seen-fire.com writes:
DF> Though double checking. It looks like rather than asking how to clone DF> the git repo. He's asking how to convert a svn based checkout to a git DF> checkout.
Yes, and then there's the issue of if LocalSettings.php can survive unscathed etc.
We also read that the SVN will continue to exist in some form. So maybe we pure downloaders don't need to do anything... for a few years.
On Wed, Feb 15, 2012 at 11:06 PM, jidanni@jidanni.org wrote:
"DF" == Daniel Friesen lists@nadir-seen-fire.com writes:
DF> Though double checking. It looks like rather than asking how to clone DF> the git repo. He's asking how to convert a svn based checkout to a git DF> checkout.
Yes, and then there's the issue of if LocalSettings.php can survive unscathed etc.
You should do a fresh clone from git rather than trying to turn a SVN repo into a Git one. Then you can just copy LocalSettings from one directory to another.
We also read that the SVN will continue to exist in some form. So maybe we pure downloaders don't need to do anything... for a few years.
Yes, we do plan to leave SVN up in read-only form for quite some time after the changeover. Be aware that once we switch, changes won't be merged back into the SVN.
-Chad
On 16/02/12 06:13, Chad wrote:
On Wed, Feb 15, 2012 at 11:06 PM, jidanni@jidanni.org wrote:
> "DF" == Daniel Friesen lists@nadir-seen-fire.com writes:
DF> Though double checking. It looks like rather than asking how to clone DF> the git repo. He's asking how to convert a svn based checkout to a git DF> checkout.
Yes, and then there's the issue of if LocalSettings.php can survive unscathed etc.
You should do a fresh clone from git rather than trying to turn a SVN repo into a Git one. Then you can just copy LocalSettings from one directory to another.
There's also images, caches... Seems easier to upgrade a svn checkout to a git one:
# You had long ago done: svn co http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/ cd phase3 echo '<?php /* Some configuration */' > LocalSettings.php
# Now you do in phase3:
git clone --no-checkout --bare --depth=1 https://github.com/mediawiki/mediawiki-trunk-phase3.git .git git config --unset core.bare git reset
Due to svn:keywords expansion you will end with 86 modified files... :(
"C" == Chad innocentkiller@gmail.com writes:
C> Yes, we do plan to leave SVN up in read-only form for quite some C> time after the changeover. Be aware that once we switch, changes C> won't be merged back into the SVN.
OK, my plan then is to do my weekly 'svn update's until I notice one day they don't update anything anymore. Whereupon I will look back at the notes in this thread and the latest official documentation on how to maintain a mediawiki site's updates via git.
On Wed, Feb 15, 2012 at 5:17 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Feb 15, 2012 at 8:09 PM, jidanni@jidanni.org wrote:
- install git (OK, apt-get install git etc.)
Actually the package is git-core.
In Ubuntu 10.04 and earlier it is "git-core". In 10.10 and forward it is "git".
They needed time to deprecate the GNU Interactive Tools "git" package after it was moved to "gnuit" in 08.10.
~Rusty
On Thu, Feb 16, 2012 at 3:29 PM, Rusty Burchfield gicodewarrior@gmail.com wrote:
On Wed, Feb 15, 2012 at 5:17 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Feb 15, 2012 at 8:09 PM, jidanni@jidanni.org wrote:
- install git (OK, apt-get install git etc.)
Actually the package is git-core.
In Ubuntu 10.04 and earlier it is "git-core". In 10.10 and forward it is "git".
They needed time to deprecate the GNU Interactive Tools "git" package after it was moved to "gnuit" in 08.10.
Ah, I didn't know the history there. Thanks for clarifying.
-Chad
On 16/02/12 02:17, Chad wrote:
On Wed, Feb 15, 2012 at 8:09 PM, jidanni@jidanni.org wrote:
- convert our maintenance scripts to use git commands instead of svn
commands. In particular for me
svn update
`git pull origin master`
Usually git pull is enough.
svn status
`git status`
It's not a simple replacement. git status can be quite unintuitive to those used to the much simpler svn status.
for i in RELEASE-NOTES-* do echo $i diff: svn diff -r ${BASE-BASE}:HEAD $i|wdiff -d -3|tee /tmp/mediawikiDiff$$ done
I think you could replace the svn line with git diff $BASE HEAD $i (HEAD being optional there)
Jidanni wrote:
for i in RELEASE-NOTES-*
do echo $i diff: svn diff -r ${BASE-BASE}:HEAD $i|wdiff -d -3|tee /tmp/mediawikiDiff$$ done
To achieve that you will have to fetch objects and references from the remote repository without changing anything locally. Then run the difference between the objects.
First find out the repository name with 'git remote':
$ git remote origin $
When cloning a repository, 'origin' is the default name.
Fetch objects from the repository:
$ git fetch origin remote: Counting objects: 37, done remote: Finding sources: 100% (22/22) remote: Total 22 (delta 13), reused 17 (delta 13) Unpacking objects: 100% (22/22), done. From ssh://to/some/path/there 81e98d4..858cf92 master -> origin/master $
Now that you have all objects from the remote repository, you can locally do a difference using 'git diff'. The syntax being:
git diff <localbranch>..<remote>/<remotebranch> [somefile]
So that would be: git diff master..origin/master
The 'git diff' command supports various options, one of them being word diff so you can probably skip the widff utility.
git diff master..origin/master --word-diff=color
To sum it up:
git fetch origin git diff master..origin/master \ --word-diff=plain \ --color=never \ RELEASE-NOTES-1.20
If your terminal supports color just --word-diff=color
Hi, I'm not involved in media wiki development but I've been through the got thing a couple of times. There's an alternative command line interface called easygit which you can download and install. It makes the learning curve shallower with more intuitive commands, more helpful output and much better man pages.
Steve On Feb 16, 2012 12:10 PM, jidanni@jidanni.org wrote:
Folks, the switchover documentation is all aimed at savvy read-write developers. We drones who just use SVN as a simple yet risky way to keep our live version of MediaWiki fresh need instructions on how to:
install git (OK, apt-get install git etc.)
convert our maintenance scripts to use git commands instead of svn
commands. In particular for me
svn update
svn status
for i in RELEASE-NOTES-* do echo $i diff: svn diff -r ${BASE-BASE}:HEAD $i|wdiff -d -3|tee /tmp/mediawikiDiff$$ done
Add notes also on how we first cd(1) to the right directory, run some command that zaps all the hidden .svn files and another command that adds all the equivalent hidden .git files or whatever.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org