Re: [Wikitech-l] Version control
On Sun, Feb 7, 2010 at 00:38, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: It's interesting that the #1 con against Git in that document is Lots of annoying Git/Linux fanboys. No, it's the screaming 'hell yeah!' but have no idea what they're talking about part. :-) g ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Version control
I believe we've had two discussions in the past on switching to git. I talked to Tim about various other advantages of .git, like the lack of autoprops annoyance, and corrected the notion that there isn't a Windows client and his reponse was maybe in a year or two. Generally the limitation is the fact that we're currently abusing svn's ability to only check out specific directories rather than an entire repo to make it easy to check out all the extensions or individual ones without any trouble. We've had ideas like using git submodules to mark stable versions of extensions so extension repos can be flexibly checked out. Oh something interesting. With a bit of trickery I recently managed to splice the entire history of one git repo into a branch of another git repo creating a git repo that has two separate initial commits in two separate branches. And from the looks of it it's perfectly possible to fetch history from the original repo into the proper branch. So it should be interestingly possible to create a script that fetches history updates for every extension at once by embedding them all into separate branches of a single git repo, and then locally (with no network latency) pulling the history from those branches into the real repos. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] Max Semenik wrote: Since there are some talks about migration from SVN anyway[1], I decided to unshelf my essay on this matter.[2] It discusses possible alternatives to Subversion and is in no way complete, everyone is invited to participate in drafting and discussing. Some sections need input of those who have practical experience with those systems, as for example I've never used Bazaar. -- [1] http://www.mediawiki.org/w/index.php?curid=44222diff=301482oldid=301369 [2] http://www.mediawiki.org/wiki/Source_control_considerations -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Version control
On Sat, Feb 6, 2010 at 21:13, Daniel Friesen li...@nadir-seen-fire.com wrote: I believe we've had two discussions in the past on switching to git. I talked to Tim about various other advantages of .git, like the lack of autoprops annoyance, and corrected the notion that there isn't a Windows client and his reponse was maybe in a year or two. Generally the limitation is the fact that we're currently abusing svn's ability to only check out specific directories rather than an entire repo to make it easy to check out all the extensions or individual ones without any trouble. We've had ideas like using git submodules to mark stable versions of extensions so extension repos can be flexibly checked out. Oh something interesting. With a bit of trickery I recently managed to splice the entire history of one git repo into a branch of another git repo creating a git repo that has two separate initial commits in two separate branches. And from the looks of it it's perfectly possible to fetch history from the original repo into the proper branch. So it should be interestingly possible to create a script that fetches history updates for every extension at once by embedding them all into separate branches of a single git repo, and then locally (with no network latency) pulling the history from those branches into the real repos. It's interesting that the #1 con against Git in that document is Lots of annoying Git/Linux fanboys. I guess this is as good a time as any to plug the git-svn notes I scribbled down yesterday: http://www.mediawiki.org/wiki/Git In order to convert to Git it would help to collect a list of things that should be split into separate repositories: * /USERINFO, /civicrm and /wikimedia-web * Everything in /trunk/* * Additionally /trunk/extensions/* and maybe some /trunk/tools/* That should yield around 500 repositories. That might sound crazy but best practice for any distributed version control system is that repositories should be split at the boundaries at which code doesn't pass over, and when's the last time /trunk/FOO shared some code with /trunk/extensions/BAR for instance? And if someone really wants to check out all 430 extensions that's easy enough with an extensions project with 430 submodules, but the most common case should be someone checking out MediaWiki.git + 3-5 extensions. I'm doing some experiments with splitting up MediaWiki's Git mirror[1] using git-filter-branch[2]. It takes a *long* time with this huge repository but a working conversion is the fastest way to get people on board. Of course this is a great chance to clean up some aspects of the repository, such as: * Rewrite the commits to give everyone real names / emails, like Tim Starling / tstarl...@wikimedia.org instead of tstarling. This can be done automatically by parsing the USERINFO files adding to them where appropriate. * Combine users like magnusmanske and magnus_manske into one * Rename/drop branches/tags if someone wants that 1. http://gitorious.org/mediawiki-svn-mirror 2. http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Version control
Since there are some talks about migration from SVN anyway[1], I decided to unshelf my essay on this matter.[2] It discusses possible alternatives to Subversion and is in no way complete, everyone is invited to participate in drafting and discussing. Some sections need input of those who have practical experience with those systems, as for example I've never used Bazaar. -- [1] http://www.mediawiki.org/w/index.php?curid=44222diff=301482oldid=301369 [2] http://www.mediawiki.org/wiki/Source_control_considerations -- Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Version control on Windows (was Wikipedia iPhone app official page?)
2009/9/5 Dmitriy Sintsov ques...@rambler.ru: * Marco Schuster ma...@harddisk.is-a-geek.org [Sat, 5 Sep 2009 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. 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) Yes. Cygwin has the same problem: it can take *ages* for a process to be forked from the command line. Running ./configure on software in Cygwin is *way* slower than on Linux. Creating processes on Windows is a heavyweight thing however you do it, it appears. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Version control systems (was: Wikipedia iPhone app official page?)
On Sat, Sep 5, 2009 at 1:34 AM, David Gerard dger...@gmail.com wrote: [subject changed] 2009/9/5 Marco Schuster ma...@harddisk.is-a-geek.org: On Fri, Sep 4, 2009 at 9:21 PM, Chad innocentkil...@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. That or Cygwin. (git works well in Cygwin too. At my last workplace we made damn sure to put Cygwin on our few Windows servers with sshd running.) Cygwin made even command-line CVS usable. Yup, cygwin is really cool... but you still need a proper GUI frontend. Windows's cmd simply sucks compared to e.g. xterm or konsole, which, of course, both can be run in cygwin. But getting X output via cygwin is a damn nightmare of a task. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
