I think it would be a good start to spice up the page and add to link to the app description on iTunes too. The description has a line saying 'come and help us if you're good in HTML5/JS!' text, but no link to follow or where to get more information (maybe somewhere in the app itself too?)

Also, why is this hosted externally on github on not in the main SVN repo?

Right now it's pretty high on the top 25 on the app store, but has a very low rating because it's obviously still in early beta and lacks many of the features found in the already existing native apps.

-- Hay

On Thu, Aug 27, 2009 at 8:15 PM, Strainustrainu10@gmail.com wrote:

On Thu, Aug 27, 2009 at 9:06 PM, David Gerarddgerard@gmail.com wrote:

...

Is there an official page for the iPhone app, other than the iTunes store link? Some sort of "about" page, a link to the source, etc.?

• d.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

See http://www.mediawiki.org/wiki/Wikipedia_iPhone_app for some info...

Strainu

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 8/28/09 12:49 PM, Chad wrote:

It's on github because that's what the Hampton likes :p Same thing with the wikimedia-mobile code. We've got several git lovers in our midst, and they're trying to stage a coup :)

Pretty much. ;)

I'm also experimenting with git for some of my private projects and for other OSS projects I poke at such as StatusNet (formetly Laconica). I'm really starting to warm up to it.

-- brion

On Fri, Aug 28, 2009 at 10:29 PM, Chadinnocentkiller@gmail.com wrote:

Blasphemy!

/me goes and sits on the SVN server and refuses to leave

We could take a look at Bazaar. It has pretty good SVN integration.You can create a (centralized) checkout of an SVN repo and when you commit into that centralized checkout from your local Bazaar branch it should commit into the master SVN as well (as I understand it). This would allow peaceful concurrent use of a centralized and decentralized version control system (although Bazaar itself supports centralized use as well). Plus it works natively on Windows without icky POSIX emulation layers.

I have not had time myself to look into the details yet, so I don't know if what I wrote actually works, but it looks promising from what I read.

Bryan

Bryan Tong Minh wrote:

We could take a look at Bazaar. It has pretty good SVN integration.You can create a (centralized) checkout of an SVN repo and when you commit into that centralized checkout from your local Bazaar branch it should commit into the master SVN as well (as I understand it). This would allow peaceful concurrent use of a centralized and decentralized version control system (although Bazaar itself supports centralized use as well). Plus it works natively on Windows without icky POSIX emulation layers.

I have not had time myself to look into the details yet, so I don't know if what I wrote actually works, but it looks promising from what I read.

Bryan

I didn't try bazaar too much, but my experience is that it works. Although I sympathise with Chad. With several SCMs out there you end up having to use (and their commands are slightly different between them :( ...).

As far as i know, the current trend is more towards Git than towards Bazaar. It's not a bad system, but Git seems to have more traction at the moment.

-- Hay

git seems to be bad at integrating with Windows.

On 8/28/09 6:49 PM, Aryeh Gregor wrote:

POSIX emulation layers aren't a problem, it's the user experience that matters in the end. On Windows, I've used SVN extensively, Mercurial a few times, and git even less. My impression is that git is still not nearly as nice on Windows as Mercurial or Subversion -- I don't think it has the fancy context-menu integration and so on. (Does it? I haven't checked lately, so I might be outdated.) If we switched to git, we might annoy some TortoiseSVN users by forcing them to switch to less convenient software.

The impression I've gotten is that Windows integration with msysgit is at least partway there now, and has improved *hugely* in the last couple years. I haven't tried it myself yet though (and would certainly not push it on everybody without doing so first!)

One of my main concerns with a git transition though is figuring out how to divide up the repository into manageable pieces; our SVN repo includes many different projects including MediaWiki core, lots of extensions, dump processing tools, our custom Ubuntu packages for Wikimedia server deployment, our load balancing tools, etc.

You don't want the complete dev history of every one of those things in your checkout, but we still want it to be easy to check out the extensions along with your copy of core.

-- brion

* Brion Vibber brion@wikimedia.org [Sat, 29 Aug 2009 09:37:08 -0300]:

On 8/28/09 6:49 PM, Aryeh Gregor wrote:

...

POSIX emulation layers aren't a problem, it's the user experience

that

...

matters in the end. On Windows, I've used SVN extensively,

Mercurial

...

a few times, and git even less. My impression is that git is still not nearly as nice on Windows as Mercurial or Subversion -- I don't think it has the fancy context-menu integration and so on. (Does

it?

...

I haven't checked lately, so I might be outdated.) If we switched

to

...

git, we might annoy some TortoiseSVN users by forcing them to switch to less convenient software.

The impression I've gotten is that Windows integration with msysgit is at least partway there now, and has improved *hugely* in the last

couple

years. I haven't tried it myself yet though (and would certainly not push it on everybody without doing so first!)

One of my main concerns with a git transition though is figuring out

how

to divide up the repository into manageable pieces; our SVN repo includes many different projects including MediaWiki core, lots of extensions, dump processing tools, our custom Ubuntu packages for Wikimedia server deployment, our load balancing tools, etc.

You don't want the complete dev history of every one of those things

in

your checkout, but we still want it to be easy to check out the extensions along with your copy of core.

Some local coder told me that GIT is slower and consumes much more RAM on some operations than SVN. I can't confirm that, though, because I never used GIT and still rarely use SVN. But, be warned. Dmitriy

@speed issues Git itself is quite fast. Claims of it being "slow" are not git itself, but on Windows the posix emulation layers it has to go through to do it's job. I'm unsure about the current state, it's possible speed has improved or the mysgit project may be more mature.

@gui Personally I use the command line for all branching operations, merges, and 99% of the time for push/pull, but git-gui while lightweight is very nice for constructing an actual commit. I prefer thinking of the gui has a helper to make some things easier, rather than a complete replacement for the cli. I haven't used it myself since I switched to Ubuntu before I ended up getting interested in git but there is a TortoiseGit project someone might want to look at for those who have been spoiled by TortoiseSVN: http://code.google.com/p/tortoisegit/

@repo breakdown I thought about that to at one point. Perhaps git submodules? git submodules are somewhat like svn:externals except they actually are built in a useful way.

To create a submodule you run: git submodule add repourl path Then you commit. This will checkout that repo to path, add the repo to .gitmodules, and tag the latest commit. Committing this will result in a submodule pointing to a specific commit in that repo being inside the repo.

When someone clones your repo submodules are not automatically checked out. You first init submodules using: git submodule init This adds the submodule repo urls into your local config. ((A very handy note here, you can actually edit the url in your config at this point, this means that while you have a public url inside the setup for submodules, individual users are free to edit the repo url for themselves and instead of the public url point their clone to a repo url where they have the ability to push to)) Then after that you run: git submodule update And it will clone all the submodules from the specific commit. Rather than cloning everything it's actually possible to use `git submodule update path` to only clone a specific repo.

To update the commit you cd into path, git pull to update to a new version, back at the root you `git add path` (be careful NOT to use a trailing / or you'll end up adding the contents of the repo into the local repo instead of updating the commit id) and commit. People can again use `git submodule update` to update everything.

submodules are probably actually faster than svn:externals and you have the option to pick and chose what you want to use.

As a thought we could probably structure it something like this: - We have a phase3 repo for MediaWiki itself - Each extension gets it's own git repo - Inside the phase3 repo we add extensions as submodules inside the extensions/ directory. -- Side note, this means we're no longer limited to a central repo for extensions. Anyone can host their extension anywhere they want and all we do is point to that repo, so we don't need to arbitrarily require they be in Wikimedia's repo for support. - On releases we create rel#_## branches in the phase3 repo. In these branches we can nicely tag commits of extensions that are stable for that version. -- This has a similar workflow as releases had in svn. When you branch the master branch to make a release it will use the commit ids that are currently there, thereby locking the commit ids for extensions in that branch just like how it works when brion svn copies phase3 and extensions to a release branch. -- As a side, it's perfectly reasonable for an extension author to go in and decide to update the commit id for an extension in a release branch if that newer commit is still stable on that version of MW. - If we don't want to bother updating commit ids inside of master (trunk) we could always just have a simple script which loops through extensions/* and for each one runs `git pull origin master` in that directory, runs git add on the paths, then commits that updating them all at once. -- Whether or not we do this, or they checkout master or a branch, anyone who checks out the repo and uses submodules to checkout extensions, they are free to use `git pull origin master` to update specific extensions to their latest trunk commit.

Under this setup someone who wanted to checkout rel1_15 MediaWiki:

git clone phase3repourl mediawiki/

MediaWiki's core code is now inside of a mediawiki/ directory

cd mediawiki/ git checkout rel1_15

We have switched to the 1_15 release

git submodule init

Submodule information added to .git/config

git submodule update extensions/

All extensions are now checked out into the extensions directory (or instead)

git submodule update extensions/ParserFunctions

Just the ParserFunctions extension is checked out

cd extensions/ParseFunctions git pull origin master

ParserFunctions is updated to it's latest alpha

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Hay (Husky) wrote:

On Sat, Aug 29, 2009 at 3:07 PM, Dmitriy Sintsovquestpc@rambler.ru wrote:

...

Some local coder told me that GIT is slower and consumes much more RAM on some operations than SVN. I can't confirm that, though, because I never used GIT and still rarely use SVN. But, be warned. Dmitriy

I'm not a git expert, but afaik Git was designed from the ground up by Linus Torvalds to be *very fast*, even on large operations. It runs the Linux project, so i guess it can't be *that* slow :)

Chad wrote:

...

It's _ok_. The command line usage is pretty solid and I haven't encountered any issues there. The GUI interface sucks and is a complete waste of time.

There aren't any real good interfaces for SVN on Mac and Linux too. Windows users are spoiled by having such a great app as Tortoise for free. I guess most Mac and Linux SVN users simply learn to use the command line, which isn't a bad thing at all.

-- Hay

On Sat, Aug 29, 2009 at 11:52 PM, Gregory Maxwell gmaxwell@gmail.comwrote:

I laughed at this... GIT has a number of negatives, but poor speed is not one of them especially if you're used to working with SVN and a remote server. Maybe this is just a windows issue? GIT leaves a lot of work to the filesystem.

And so to the disk. If the disk or the controller sucks or is simply old (not everyone has shiny new hardware), you're also damn slow. What should also not be underestimated is the diskspace demand of a GIT repo - not everyone has the money to buy new, high-sized disks (or has not the possibility to upgrade, especially laptop users). Of course, the diskspace issue can be solved partially by splitting that what is now one big SVN repo to multiple smaller ones - a standard GIT pull should e.g. not include the custom MWF stuff or the sources of the helper tools/scripts and whatever is hidden in the deep world of svnroot. Marco

On Sat, Aug 29, 2009 at 8:37 AM, Brion Vibberbrion@wikimedia.org wrote:

One of my main concerns with a git transition though is figuring out how to divide up the repository into manageable pieces; our SVN repo includes many different projects including MediaWiki core, lots of extensions, dump processing tools, our custom Ubuntu packages for Wikimedia server deployment, our load balancing tools, etc.

I'd say put extensions and core in one repo, and make different repos for everything else that's logically separate and unlikely to move from repo to repo. Or we could have core in one repo, and use submodules for extensions.

On Sat, Aug 29, 2009 at 9:07 AM, Dmitriy Sintsovquestpc@rambler.ru wrote:

Some local coder told me that GIT is slower and consumes much more RAM on some operations than SVN. I can't confirm that, though, because I never used GIT and still rarely use SVN. But, be warned.

I hope we can do better than vague second-hand rumors when considering easily quantifiable things like performance. In my experience, git is much faster than SVN on many operations simply because it doesn't need to go to the server. blame is often fast enough that you can do them without feeling much urge to switch to another window while you wait. log, diff (even for old revisions), etc. are nearly instantaneous.

Just out of interest, I once timed a fresh SVN checkout of trunk/ from svn.wikimedia.org to the toolserver (so they were even in the same datacenter). Then I tested a git clone of a git-svn checkout of the *entire* mediawiki/ repository, including trunk, branches, tags, and all history, from a server I have (in Denver) to the toolserver (in Amsterdam). The git clone was *significantly* faster. (To be fair, it *was* http:// vs. git://, but still.)

Another interesting data point: an SVN checkout of trunk/, with working copy, is 696M. A git svn checkout of the entire repository with branches, tags, and all history, plus working copy, is 661M after git gc. (But admittedly, before git gc it was 1005M. Not too bad anyway: 44% more for branches+tags+history.)

So I'm going to say that this claim completely contradicts my experience using both git and SVN (and I've used both fairly extensively). Of course, I'm sure there are "some operations" where git is slower than SVN, but that's not a very useful claim, given that the converse is certainly true.

The only time I've found where git performance was totally unacceptable when I tried to use it for compression/versioning of >1G database backups -- git add used up multiple gigabytes of RAM and OOMed when I tried to add the first file. The lesson there, obviously, is that git is meant to version source code, not files as large as database backups. git is known not to do so well on extremely large repos. It also has some trouble if you have lots of large binary files that change a lot -- those can't be compressed easily, especially if they're already compressed somehow.

On Sat, Aug 29, 2009 at 5:38 PM, Daniel Friesenlists@nadir-seen-fire.com wrote:

As a thought we could probably structure it something like this:

• We have a phase3 repo for MediaWiki itself

One objection: could we please rename phase3 something sensible like "mediawiki" if we do this? :)

On Sat, Aug 29, 2009 at 6:48 PM, Marco Schustermarco@harddisk.is-a-geek.org wrote:

And so to the disk. If the disk or the controller sucks or is simply old (not everyone has shiny new hardware), you're also damn slow.

Um, and SVN won't be? Do you have actual benchmarks indicating that git is slower than svn on *any* typical distributed source-control workload?

(By "distributed" I mean "with the remote server over the Internet". I could well believe that if you're in an office where the remote server is on a LAN, and the remote server happens to have 8 15k RPM SCSIs and 16G RAM while your workstation is a three-year-old consumer desktop, SVN would be a lot faster. SVN might be better for other things as well, like anything involving very large files or very large repos. But none of these are applicable to us.)

What should also not be underestimated is the diskspace demand of a GIT repo

Have you actually tested the disk space usage side-by-side? Because my figures (from above) indicate that git doesn't use much more disk space than SVN at all. SVN doesn't compress its .svn directories at all AFAICT -- git uses extremely heavy-duty compression.

On Fri, Sep 4, 2009 at 3:15 PM, David Gerarddgerard@gmail.com wrote:

2009/8/29 Brion Vibber brion@wikimedia.org:

...

The impression I've gotten is that Windows integration with msysgit is at least partway there now, and has improved *hugely* in the last couple years. I haven't tried it myself yet though (and would certainly not push it on everybody without doing so first!)

Someone's now doing TortoiseGit:

http://code.google.com/p/tortoisegit/

• designed to work just like TortoiseCVS and TortoiseSVN.

(I put that link on Twitter and so far one person has said it's fantastic and "goodbye svn, hello git!" - I prefer the command line so have no idea, but it augurs well and the Windows users here might want to try it out  :-) )

• d.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wheee! TortoiseSVN indeed spoils us Windows users, as it's made version control so easy that...well...a Windows user can do it ;-)

-Chad

* Marco Schuster marco@harddisk.is-a-geek.org [Sat, 5 Sep 2009 01:29:24 +0200]:

On Fri, Sep 4, 2009 at 9:21 PM, Chad innocentkiller@gmail.com wrote:

...

Wheee! TortoiseSVN indeed spoils us Windows users, as it's made version control so easy that...well...a Windows user can do it ;-)

If Windows had a decent command line / shell (has its suckyness

improved

for Win7?), I bet that TortoiseSVN had far less downloads... it simply is the only way to make SVN usable on Windows.

Marco

Old Windows Shell will be replaced by this one: http://en.wikipedia.org/wiki/Windows_PowerShell But I've read long time ago that usability of Windows Shells is limited not just because the syntax is weak, but, what's more important, process startup delay is much longer than in Linux, thus, calling of lots of external console programs to perform complex actions would be much slower at the same machine. My own scripts (eg mediawiki video sitemap generator seem to prove that) Dmitriy