This is partial summary of Git User's Survey 2008 for the state from Sep 09, 2008, with almost 2300 responses (yes, _thousands_ responses). It is based on "Analysis" page for this survey: http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8 We have around 2295 individual responses (excluding 21 responses in the 'testing' channel), for the time I got those data, as compared to 683 individual responses for 2007 survey, and (I think) 115 answers (Base = 115) for 2006 survey. That is a lot,... I wonder how many replies we would have at the end of survey, Oct 10? --- Below I concentrated on questions related to other SCM, although not all those questions were from "Other SCM" section. 12) What other SCM did or do you use? (Matrix - One answer per row) The table below is sorted alphabetically, with exception of 'custom' and 'other' which are put at the end. ============================================================== SCM | Never | Used it | Still use -------------------------------------------------------------- AccuRev | 60% (1227) | 0% (6) | 0% (1) Arch (or clone) | 54% (1108) | 7% (136) | 0% (1) 11 Bazaar-NG | 47% (969) | 12% (257) | 4% (76) 7 BitKeeper | 55% (1135) | 5% (111) | 0% (3) 12 ClearCase | 53% (1101) | 7% (151) | 2% (37) 10 CVS | 12% (242) | 62% (1277) | 13% (260) 1 Darcs | 48% (990) | 13% (262) | 2% (48) 6 Mercurial | 40% (819) | 18% (379) | 8% (174) 5 Monotone | 55% (1136) | 5% (95) | 1% (16) 14 MS SourceSafe | 46% (949) | 19% (401) | 1% (20) 3 MS Studio Team System | 57% (1173) | 3% (56) | 0% (9) Perforce | 51% (1045) | 9% (191) | 3% (64) 9 PVCS | 56% (1157) | 5% (100) | 0% (3) 13' RCS | 43% (881) | 19% (389) | 3% (59) 4 SCCS | 56% (1146) | 5% (100) | 0% (7) 13' Subversion | 3% (59) | 35% (726) | 59% (1217) 2 SVK | 51% (1043) | 11% (226) | 1% (15) 8 .............................................................. custom (non-published) | 54% (1115) | 4% (90) | 1% (22) other | 51% (1042) | 5% (98) | 1% (22) -------------------------------------------------------------- Total respondents | 2060 skipped this question | 235 Side note: each of version control systems have at least one respondent which still use it. That was not assured. Top 5 "still use", which should mean version control system which are used beside, and together with Git. ===================================== SCM | still use ------------------------------------- 1. Subversion | 59% (1217) 2. CVS | 13% (260) 3. Mercurial | 8% (174) 4. Bazaar-NG | 4% (76) 5. Perforce | 3% (64) ..................................... 7. Darcs | 2% (48) 10. Monotone | 1% (16) Note that 10th place for Monotone excludes 'custom' and 'other'; otherwise it would be 12th. Analysis: Subversion (SVN) is most popular, eclipsing all other SCMs. This might be caused by the fact that git-svn is very good in integrating Subversion with Git enhances and emphasizes popularity of Subversion. CVS, at time very popular, leaves the field to Subversion (advertised as replacement fo CVS, as "CVS done right") and other systems. This agrees with the number of people which have above version control systems in Ohloh software stack [need new analysis for final version; for now you can use data from GitSurvey2007 page at git wiki], and with Debian Popularity Contest (popcon) [here also new data is needed]. A bit suprising for me is high place of Perforce. Another strange thing (and a bit alarming) is that MS Visual SourceSafe has higher place than Monotone; but that might be caused by different design and different target groups of Monotone and Git, which might have caused that the communities have almost no overlap; people choose either Git or Monotone, one or the other. BitKeeper has also a very low number of active users among Git users... but that is not that strange, considering history. See also "Adoption of various VCSes" blog post by Newren: http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/ which is less than year old. This essay includes proprietary SCMs like Perforce. Top 5 "used it" (assumption: no longer in use) version control systems. Replaced by Git or other SCM, tried and abandoned, etc. ===================================== SCM | used it ------------------------------------- 1. CVS | 62% (1277) 2. Subversion | 35% (726) 3. MS SourceSafe | 19% (401) 4. RCS | 19% (389) 5. Mercurial | 18% (379) ..................................... 6. Darcs | 13% (262) 7. Bazaar-NG | 12% (257) 14. Monotone | 5% (95) Note that again 'other' and 'custom' are excluded. Analysis: We can see here former glory of CVS, which was once standard for version control system. Its predecessor, single-file locking version control system, RCS is also visible. A bit suprising is 3rd place of MS Visual SourceSafe; I really hope that it is either "I took a look at it and ran away", or "I had to use it but fortunately no longer". And what do you think about this? 13) Why did you choose/use Git? (if you use Git) What do you like about using Git? (Open ended text - Essay) Total respondents 1723 skipped this question 572 14) Why did you choose/use other SCMs? (if you use other SCMs) What do you like about using other SCMs? (Open ended text - Essay) Total respondents 1329 skipped this question 966 25) How do you publish/propagate your changes? (Choice - Multiple answers) ====================================== method | using it -------------------------------------- push | 91% (1740) pull request | 29% (551) format-patch + email | 22% (414) git bundle | 2% (39) ...................................... git-svn | 26% (498) other foreign SCM^[*] | 2% (45) ...................................... other | 2% (32) ====================================== Total respondents | 1904 skipped this question | 391 Footnote: ========= [*] publishing to other foreing SCM: + Bazaar, using git-bzr + CVS, using git-cvsexportcommit using git-cvs (probably git-cvsserver) + ClearCase, using custom scripts unspecified method + Perforce, using git-p4 using git-p4-import using patch + Mercurial, using fast-import (?) using email + hg mq + AccuRev, using git-acu + Quilt, using email + SourceSafe, using shared workdir using custom scripts + Subversion, using shared workdir (?) + SVK, using shared workdir + RCS, using custom scripts + TeamWare, using git-tw (unpublished yet) Analysis, as pertinent to "other SCM" question: as you can see git-svn is very popular, just below pull request (which probably include GitHub social interface), and slightly higher (!) than format-patch plus email, i.e. patch-based workflow. 26) If the way you publish your changes is not mentioned above, how do you publish your changes? Please explain. (Open ended text - Essay) Total respondents 95 skipped this question 2200 Here are listed only methods which are truly not mentioned above (for example publishing to other SCMs usually doesn't count). I have also tried to remove duplicated entries: * git-bzr allows for bidirectional syncing with a git repository. Useful when a project is hosted in Bazaar. * Standard diff file encompassing all changes for a specific feature. * On one machine, I use rsync to push my repository upstream by hand (for HTTP access). * Personal use only (many responses). * we also use a script that uses various git=diff concoctions to generate patch bundles * format-patch + lighthouse; We create patches and attach to tickets in Lighthouse (lighthouseapp.com) for several open-source projects. * Patches on reviewboard * format-patch and attach to bugtracking system * Just so I can be a little more specific about how I publish. I primarily use stgit and then put the patches in an issue tracker (like trac). * I do format-patch. Then I've written a script that posts to pastebin.com My friend uses another script that downloads from pastebin.com ;) NOTE: why don't use gist.github.com, or even just GitHub... * forum or IRC to the project owners * format-patch and uploading to a webserver. * format-patch + save patch on wiki page * "git diff > my.patch" and upload to the drupal.org issue queue. * after-push hooks on github to campfire/lighthouse/twitter * GTP (Git Torrent Protocol -- my own implementation) * git archive * gitweb's snapshot/tarball plugin * Since my hosting provider is temperamental, I have many projects in a strange hierarchy, and I want to recreate my repository precisely, I just tar up my master folder and upload that. * Because of a retarded network setup out of my control, I use a disgusting script based on git clone --bare, tar, scp, ssh, and rsyncing. * Sometimes as simple and stupid as tarball / scp * Transport of entire repositories via CD/DVD. NOTE: wouldn't it be easier to use USB stick and bundles? * copy the whole changed file or tell them what to change since some windows people do not know what a patch is or how to apply it :-/ * I use git for a repo with lots of huge files (RAW image files). git pull/push insists on packing up objects but I'd rather have one object per file in .git/objects, so I rsync those and then pull the changeset history via std means. * For all my projects, I set up a post-update hook on my dreamhost account to force update. I use a standard remote named "stage". * Package a RubyGem and upload it to the files area of the relevant RubyForge project, and make sure the same RubyGem is in my Git repo so GitHub will generate a gem as well. * Custom scripts for pull requests and patchbombing An interesting comment: * At work I use git for tracking one project I work on. It is a project with Unix line endings in some files, and Windows file endings in the other. My company uses VSS which cannot handle Unix line endings and otherwise is not very powerful. So I use git to track my history, but use VSS as backup repository. Also I git pull my git repository to a backup repository on a network drive. An explanation of choices: * There are cases where I will push to continuous integration repositories to get a specific tree tested. Otherwise it is all about pulling. * I do not publish my changes. Other people can access a copy of my code, but I do not use a git repository on a server. I do not understand that concept good enough (hint: that needs docs for total dummies) * I only use git for cloning/pulling repo's for now, since it is too hard to use. I don't have a lot of spare time to learn it since svn is easy and useful. I would use it if there was a doc that explains it to us svn people. And there is also: * For 27 and 28, there is no "I don't know< I'm using the GUI's", so I'm not ticking the answers * I don't know! * GitHub; Gitosis; Capistrano * Send them to somebody who has git access. NOTE: probably format-patch + email * can some one provide free private git service? ANSWER: There are many free _public_ git service, and a few non-free git services offer private repositories (e.g. GitHub) * Carrier pigeon Analysis: as you can see format-patch + <something>, where <something> is not email or mailing list, but issue tracker, wiki, patch queue or other web site/web application is quite popular. Some people use different combinations of tar/zip and scp or other transport, or rsync, or ssh to simply transfer the whole repository (some of which might be migitated by using bundles instead, but only if there is access to shell account on remote site and there is git on remote site to "unpack" bundle). Sometimes it is caused by the lack of decent features in a web server, sometimes it is lack of knowledge. 15) Do you miss features in git that you know from other SCMs? If yes, what features are these (and from which SCM)? (Open ended text - Essay) Total respondents 1046 (some/many of them wrote 'no') skipped this question 1249 This is just a very quick summary, based on a first few pages of responses, Full analysis is I think best left for after closing the survey, because I think this would be a lot of work... So here is preliminary list, or rather beginning of one: * sparse/partial checkout and clone (e.g. Perforce) * better MS Windows support (CVS, Mercurial, Darcs, Bazaar) * integration with IDE/RAD/editor/filemanager * good GUI/visual tools/graphical shell (on multiple platforms) * 'soft' locking aka. watching files (like in ClearCase) * equivalent of 'hg serve': fast web interface and pull-server in one (Mercurial) * better documentation (svnbook, hgbook, generic) * traversing history of individual file (unknown SCM) * better interface for staging individual changes (Darcs interface is better than 'git add -i') * better UI for submodules (less commands to issue, like in Subversion) * integrated conflict resolution tool * tracking empty repositories (Bazaar) + It would be helpful to have something like "comments" in monotone. + hackability and portability of Mercurial + good Unicode support, the current implicit handling sucks + Hg had less commands to do the same :) (Mercurial) + big file support (ClearCase) + maybe a 'info' style command where it lists all branches, tags, remotes and repo specific config. Rather than using separate commands. + I don't miss any *feature* from SVN, but I do miss some of the terse commands. Reverting my local changes to a file in Git always feels like hard work, and in SVN it's a dead simple command, etc. + svn:externals from subversion (especially the part where one can do partial imports from other repositories) something in the likes of hgforest, i.e. having 'live' submodules which are not fixed to a specific revision (from Mercurial) * better support for tracking third party tools like 'piston' for Subversion. NOTE: there is 'braid', formerly 'giston' for git * mainly fine-grained commit support (staging diff hunks), branch management, stashing NOTE: all of this is available in modern Git * easier to use commit identifiers. "It's hard to memorize the seemingly random commit hash (even the short 7-character ones)." Note that people used this question to put feature requests, instead _only_ things from other SCMs that they are missing in Git; and even when they did correctly, they forgot often to state _which_ SCM is given feature from. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
