I have tried a few times to add information about Git to comparison table of SCMs at 'Better SCM Initiative' (http://better-scm.berlios.de) http://thread.gmane.org/gmane.comp.version-control.git/66445 http://thread.gmane.org/gmane.comp.version-control.git/67708 but somehow I didn't lead it to conclusion, namely adding Git to the comparison table. (Sidenote: Data from 'Better SCM : Comparison' is used also for versioncontrolblog "Version control systems comparison" at http://versioncontrolblog.com/comparison). I have thought about trying yet another time... but Git was already added; see http://better-scm.berlios.de/news/changes-2008-08-07/ Now I have checked information about Git and think that this table needs a few corrections and, in some places, extra explanation. Let us here come together with a version we can be happy with, which I would be then able to send as correction for Better SCM Initiative comparison (http://better-scm.berlios.de/contribute/). Below there are excerpts from source of comparison table (from SVN) http://opensvn.csie.org/betterscm/better-scm-site/trunk/src/comparison/scm-comparison.xml marked as quoted text (with 'scm>'), optionally un-indented and re-wrapped for better readibility. My comments follow as if they were replies to an email. --- scm> <?xml version='1.0' encoding='utf-8'?> scm> <?xml-stylesheet type="text/xml" href="compare-ml.xsl"?> scm> <!DOCTYPE comparison SYSTEM "comparison.dtd"> scm> <!-- scm> TODO: scm> scm> * Add intelligent merging of renamed paths. The comparison has a new criterion: "Intelligent Merging after Moves or Renames" since 2008-08-07, so the first item in this TODO list should have been removed, I think. scm> * Add IDE integration. scm> * Integration with build/testing management. scm> * Check-In policies. scm> * Add Speed (?) scm> --> The problem of course with adding new criterion is that it should be added for _all_ (currently 27) version control systems (SCMs) covered. scm> <comparison> scm> <meta> scm> <implementations> scm> <impl id="git"> scm> <name>Git</name> scm> <url>http://git.or.cz/</url> scm> </impl> Hmmm... what to do about the fact that currently Git has _two_ forks of a homepage: http://git.or.cz (aka http://git-scm.org) by Petr 'Pasky' Baudis and new http://git-scm.com by Scott Chacon, I do wonder... But those are just aimless musings... the above is O.K. scm> </implementations> scm> <timestamp> scm> $Id: scm-comparison.xml 322 2008-08-09 05:47:26Z shlomif $ scm> </timestamp> scm> </meta> scm> <contents> scm> <section id="main"> scm> <title>Version Control System Comparison</title> scm> <expl> scm> This is a comparison of version-control systems. It is split scm> into several categories and sub-categories under which the scm> systems are checked. scm> </expl> scm> <section id="repos_operations"> scm> <title>Repository Operations</title> scm> <section id="atomic_commits"> scm> <title>Atomic Commits</title> scm> <expl> scm> Support for atomic commits means that if an scm> operation on the repository is interrupted scm> in the middle, the repository will not be scm> left in an inconsistent state. Are the scm> check-in operations atomic, or can scm> interrupting an operation leave the scm> repository in an intermediate state? scm> </expl> Here I think the explanation of a criterion (feature) is clear enough. I might have added that "interruption" include killing of a process during for example commit, lack of disk space for a full commit, or a network fail during network operation (fetch or push, or equivalent). scm> <compare> scm> <s id="git">Yes. Commits are atomic.</s> scm> </compare> O.K. scm> </section> scm> <section id="move"> scm> <title>Files and Directories Moves or Renames</title> scm> <expl> scm> Does the system support moving a file or directory to scm> a different location while still retaining the history scm> of the file? <b>Note:</b> also see the next section scm> about intelligent merging of renamed paths. scm> </expl> In my opinion this criterion is next to worthess without more in depth clarification of what does it mean to "support" moves or renames; as entries for different systems are written by different people, if it is not clear how to check if some feature is supported, some might write 'no' for some system A, and some other person can write 'yes' for other system B, even if the support is better in system A than in system B (and would be considered enough, i.e. 'yes' answer, by the creator of this criterion). For me the support for renames/moves and copying (see next section) means that: 0.) When examining or going to some point in the history (some old revision/version of a project) the state you get is _exactly_ the same as it was at that time, exactly the same as it was recorded (comitted) then. For example tricks with moving *,v files in the CVS repository break this assertion. 1.) When examining history of a project as a whole version control system tells you that file was renamed (moved). I would consider having there renaming represented as copy + delete to be only a partial support of this feature. Note that while tool might correctly notify about file renames (I would consider heuristics which give correct answer in 99% or so "true life" example to 'correctly notify'), it might notice full directory renames only as renames of individual files. I guess that at least for some systems this issue was not taken into account... 2.) When examining history of an individual file (or perhaps even of an individual directory), either in the form of list of revisions which touch given file in the form of "$scm log <file>" output or some graphical history viewer output, or in the form of annotations of file contents (so called here 'per-line history') in the form of "$scm blame <file>" / "$scm annotate <file>", we would want for SCM to follow history of contents across file renames (and other code movements if possible; but that is outside of scope of this criterion). Side note: history of two files can be more than sum (union) of histories of individual files. >From the comments I have heard it looks like at least for some version control systems contributors used the meaning '0', while most users (readers) would think of '1+2', good if not forgetting about '0'. Here (and in other places) it would be nice to have actual *TEST*, which can be used to determine if given version control system "supports" 'Files and Directories Moves or Renames' criterion/feature. Attention! because Git does similarity based rename detection (contents + pathname based similarity score), one should use better some larger test vector, otherwise Git and other systems using rename detection would be at disadvantage. An example of such test would be t/t*rename* tests from git; we could also use 'Lorem ipsum' or 'Dominus regit me' test vectors. So for example 1.) could be tested as: $ scm add A $ ... $ scm mv A B $ ... $ scm log [options] # <- has info about A => B rename while 2.) could be tested as: $ scm add A $ ... $ scm mv A B $ ... $ scm log [options] B # <- goes to initial revision of A By the way, there is even simpler operation than support for renames that SCM can screw up (file-history based SCM are specially susceptible). Try to delete a file, and then later create _different_ file (separate history) with the same filename. scm> <compare> scm> <s id="git"> scm> Renames are supported for most practical scm> purposes. Git even detects renames when a file has been scm> changed afterward the rename. However, due to a peculiar scm> repository structure, renames are not recorded scm> explicitly, and Git has to deduce them (which works well scm> in practice). scm> </s> First, a correction to above statement. It is not due to "a peculiar repository structure", but due to "a design decision" (perhaps with link to some explanation why it was implemented this way; I planned to make a wiki page about 'rename tracking' vs. 'rename detection' with references to various mailing list messages etc., but to this day it was not created). Second, we can think about how the above statement could be improved. For example Git fullfils '0' even without rename detection, due to the fact that it is whole-tree snapshot-based VCS. From descriptions for other version control systems (see "Version Control System Comparison" subpage of "Better SCM Initiative : Comparison" at http://better-scm.berlios.de/comparison/comparison.html) it looks like at least some contributors thought that having '0' supported is enough to say 'Yes' to this question. Git uses rename detection, not rename tracking (usually file-id/inode based) to be able to notify about renames in the diff / whatchanged / diffstat or summary output. So I would say that in practice (with some unfortunate exceptions) Git fills '1', which means showing renames in whole project log well. When talking about rename detection for a single file history, here the situation gets difficult. On the one hand "git log --follow <file>" is a bit of hack and works only for simple histories, failing for example on subtree merge; other example would be 'gitweb/gitweb.perl' file in git repository, which '--follow' doesn't follow to initial 'gitweb.cgi' file from what once been gitweb repository. One has to use then "git log -- <old name> <new name>"; this is caused by the fact that git always concentrated more on full repository history, and by how path limiting works. On the other hand Git has as far as I know _unique_ blame tool which is able to follow code movement; this covers more than only following contents across wholesame file rename. This feature IMHO is best examined using "git gui blame <file>" or other graphical blame/annotate viewers (QGit has one, for example). To be honest git currently does not have _directory_ rename detection (which for example leads to some quirks in dealing with renames during merge, to be more exact dealing with new files in a directory which got renamed by other side); it currently supports directory renames by detecting renames of files it contains (path similarity is part of rename-detection similarity score). But this is not insurmountable obstacle, and does not require changing design and tracking renames. ...Now only put the above in a few short sentences to be used in "Better SCM Initiative" comparison table... scm> </compare> scm> </section> scm> <section id="intelligent_renames"> scm> <title>Intelligent Merging after Moves or Renames</title> scm> <expl> scm> If the system keeps tracks of renames, does it support scm> intelligent merging of the files in the history after scm> the rename? (For example, changing a file in a renamed scm> directory, and trying to merge it). scm> </expl> Here also the criterion is not completly clear. The example helps a little, but it should perhaps be expanded a little. I don't know also why the example is unnecessary complicated, with renaming directory; perhaps this version is shorter to describe. For me "Intelligent Merging after Moves or Renames" consist of the following items: merging renames, applying change to correct file, dealing with renamed directories, and new merge conflict types related to renames and similar things. Let me explain each concept with a little test case checking if given SCM support respective feature: * merging renames: if one side renamed file you should get rename on merge; renaming a file and then merging that rename. [on branch b]$ scm mv foo bar [on branch a]$ scm commit ... # to not have fast-forward case [on branch a]$ scm merge b expected result> you have file 'bar', and do not have file 'foo' * applying change to correct file: if our side renamed a file (or, as in above example rename directory it is in, which does rename full pathname of a file indirectly), and possibly change it, and the other side changed file, we would want merge to bring changes to file after rename. [on branch a]$ scm mv foo bar [on branch a]$ edit bar && scm commit # optionally [on branch b]$ edit foo [on branch b]$ scm commit -m 'FOO' [on branch a]$ scm merge b expected result> you have changes made on branch 'b' to file 'foo' (commit 'FOO') in file 'bar' Note that like in example in previous item all operations take place _after_ branching point (after creation of branch b off branch a). This is I guess what most people think when talking about rename-aware (intelligent) merging. * renamed directories bring another complication (described for example on Mark Shuttleworth blog in articles about DVCS, promoting Bazaar-NG), namely how to deal with merging changes where other side creates _new files_ in renamed directory. [on branch a]$ scm mv subdir-foo/ subdir-bar/ [on branch b]$ scm add subdir-foo/baz [on branch a]$ scm merge b expected result> New file subdir-bar/baz There is a bit of controversy about this feature, as for example in some programming languages (e.g. Java) or in some project build tool info it is not posible to simply move a file (or create new file in different directory) without changing file contents. Some say that is better to fail than to do wrongly clean merge. scm> <compare> scm> <s id="accurev"> scm> Unknown. FILL IN. scm> </s> As you can see it is new criterion :-) scm> <s id="git"> scm> No. As detailed in the <a scm> href="http://git.or.cz/gitwiki/GitFaq#rename-tracking";>Git scm> FAQ</a>: scm> "Git has a rename command git mv, but that is just a scm> convenience. The effect is indistinguishable from removing scm> the file and adding another with different name and the scm> same content." scm> </s> This is of course NOT TRUE. If the author bother checking (which would be helped if there was available simple shell script, or simple Perl script, testing 'intelligent_renames' criterion) he/she would notice that git does apply change to renamed file, both if file itself is renamed, and if directory it is in gets renamed. If I understand correctly dealing with file renames and moving files around (one could say: refactoring directory hierarchy/structure) was main reason (or one of main reasons) for adding rename detection to Git. In practice it works quite well (which for the test mean testing with large enough contents to be able to use similarity based rename detection). What Git _currently_ doesn't support (at least for now, with lack of detection of directories as a whole) is with adding new files to the renamed directory, as described a bit above. scm> <section id="copy"> scm> <title>File and Directories Copies</title> scm> <expl> scm> Does the version control system support copying scm> files or directories to a different location at the scm> repository level, while retaining the history? scm> </expl> The same complaint as with the "File and Directory Moves or Renames". What does "support copying" mean for SCM in question, in this context? scm> <compare> scm> <s id="git">No. Copies are not supported.</s> scm> </compare> To a large extent NOT TRUE. Copies _ARE_ supported in Git using the same mechanism of similarity based detection as for renames. There are however some caveats and limitations compared to rename detection. First, you have to enable copies detection. While it is not uncommon to have rename detection turned on (I'm not sure if it is not on by default, for example for git-show; nevertheless you can turn it on for diffs using diff.renames configuration variable, and for example gitweb web interface by default detects renames), it is much less common to have copies detection turned on by default, as it is more expensive operation. Second, for performance reasons Git finds copies only if the original file of the copy was modified in the same changeset. You can search for copies in all files, but it is much more expensive operation. On the other hand git-blame can be asked to deal with code copying, even across files; as far as I know Git is the _only_ SCM which has file line provenance annotation tool which supports this. scm> <section id="repos_clone"> scm> <title>Remote Repository Replication</title> scm> <expl> scm> Does the system support cloning a remote repository to get scm> a functionally equivalent copy in the local system? That scm> should be done without any special access to the remote scm> server except for normal repository access. scm> </expl> This means either that SCM in question is distributed, or that there exists some replication / morroring tool (for centralized SCMs). scm> <compare> scm> <s id="bazaar">Yes.</s> scm> <s id="darcs">Yes.</s> scm> <s id="mercurial">Yes.</s> scm> <s id="monotone">Yes.</s> scm> <s id="git">Yes. This is very intrinsic feature of Git.</s> In fact this is 'very intrinsic feature' of each distributed SCM... well, unless one takes into account difference between single-branch or workdir-per-branch distributed SCM and multiple-branch-per-repository distributed SCM. Then this is a bit more complicated. In short: I think that simple 'Yes.' answer for Git would be better. scm> <section id="push"> scm> <title>Propagating Changes to Parent Repositories</title> scm> <expl> scm> Can the system propagate changes from one repository to scm> another? scm> </expl> O.K. scm> <compare> scm> <s id="mercurial">Yes.</s> scm> <s id="monotone">Yes.</s> scm> <s id="git">Yes. (The Linux kernel development process uses this extremely often).</s> scm> </compare> scm> </section> I'm not sure if this comment is there really necessary. I would avoid it, especially that as far as I understand Linux kernel development uses patch+email based system as extensively or even more extensively, at least onlietenants level. scm> <section id="permissions"> scm> <title>Repository Permissions</title> scm> <expl> scm> Is it possible to define permissions on access to different scm> parts of a remote repository? Or is access open for all? scm> </expl> Side note: Karl Fogel in his book "Producing Open Source Software. How to Run a Successful Free Software Project" (http://producingoss.com) wrote basing on his work on _Subversion_ (which is centralized SCM), that there are usually many advantages to use 'honor system' instead of repository permission, i.e. use social solution than technological solution, see "Chapter 3. Technical Infrastructure", section "Version Control", subsection "Authorization" http://producingoss.com/en/vc.html#vc-authz Distributed version control systems like Git, Mercurial or Bazaar-NG offers even wider selection of ways to implement 'honor system', and solve "Repository Permissions" problem using social solution. [Here would be nice to have link to discussion of "Prodicting OSS" book on git mailing list, and to article discussion it] scm> <compare> scm> <s id="bazaar"> scm> Basic access control can be implemented through a scm> contributed hook script. ACL support for the scm> Bazaar server is planned. scm> </s> scm> <s id="mercurial"> scm> Yes. It is possible to lock down repositories, scm> subdirectories, or files using hooks. scm> </s> scm> <s id="monotone"> scm> Yes. It is possible to restrict incoming changes scm> from certain sources to be performed only in certain scm> parts of the repository. scm> </s> [...] scm> <s id="git"> scm> No, but a single server can serve many repositories. scm> Also, UNIX permissions can be used to some extent.</s> scm> </compare> scm> </section> Side note: why Git entry was not word-wrapped like the entries for most other SCM, but used single long line? I have rewrapped it for better readibility. First, there is possible to lock down repositories, using permissions of underlying protocols (SSH, WebDAV), or using additional tools like Gitosis, ssh_acl or example hook contrib/hooks/update-paranoid. It is possible to lock down (limit access to) branches and tags, which is not mentioned as scope of this criterion, and I think is more important feature. Second, I think it is possible to restrict incoming changes from certain sources to subdirectories or files using hooks; but as far as I know there doesn't exist any such example hook. And third, it is not as important for distributed SCM to have fine-grained technical solution when there are many social solutions to this problem; for example in Git when you do a pull from other repository it would (usually) show you diffstat of changes, so you can easily see if there were changes made outside some directory limits. scm> <section id="changesets"> scm> <title>Changesets' Support</title> scm> <expl> scm> Does the repository support changesets? Changesets are a way scm> to group a number of modifications that are relevant to each scm> other in one atomic package, that can be cancelled or scm> propagated as needed. scm> </expl> Here it is not entirely clean what creator of "Better SCM Initiative" comparison table had on mind, what he meant by this. Not all version control systems are changeset based; some are snapshot based. I guess that for snapshot based SCM the above requirement is equivalent to "Whole tree commits". scm> <compare> scm> <s id="cvs">No. Changes are file-specific.</s> scm> <s id="subversion">Partial support. There are implicit scm> changeset that are generated on each commit. scm> </s> scm> <s id="bazaar"> scm> Yes. Changesets are supported. scm> </s> scm> <s id="darcs"> scm> Yes. Changesets are supported. scm> </s> scm> <s id="mercurial"> scm> Yes. Changesets are supported. scm> </s> scm> <s id="monotone"> scm> Yes. Changesets are supported. scm> </s> scm> <s id="git"> scm> Yes, Changesets are supported, scm> and there's some flexibility in creating them. scm> </s> scm> </compare> scm> </section> [Again, Git part was re-wrapped for better readibility] In my opition, such an _empty_ addition ("there's some flexibility in creating them") is totally unnecessary; it adds no solid information (what does it mean "some flexibility") and should be removed. If it was about Git being at the heart snapshot based rather than delta (changeset) based, then it should be reworded to make it clear (if deemed to be necessary). scm> <section id="annotate"> scm> <title>Tracking Line-wise File History</title> scm> <expl> scm> Does the version control system have an option to track the scm> history of the file line-by-line? I.e., can it show for each line scm> at which revision it was most recently changed, and by whom? scm> </expl> Here it would be nice to have example of such output, but I think everyone knows what this criterion means in the term of SCM features. scm> <compare> scm> <s id="git">Yes. (git blame).</s> scm> </compare> Perhaps we could also add that git-blame supports (if requested) tracking changes across code movement and code copying (crossing file boundaries if necessary, and can ignore changes in whitespace. And there is also "pickaxe" search, which can find deleted contents, which is one of major limitations of usability of line-wise file history (line provenance) annotations. On the other hand because Git is based towards whole project history, and not per file history, git-blame is slow. To migitate that there is incremental blame mode used to reduce latency in graphical blame viewers like "git gui blame", contrib/blameview, or the one in QGit. scm> <section id="features"> scm> <title>Features</title> scm> <section id="work_on_dir"> scm> <title>Ability to Work only on One Directory of the Repository</title> scm> <expl> scm> Can the version control system checkout only one directory of scm> the repository? Or restrict the check-ins to only one scm> directory? scm> </expl> This is combination of "restricted check-ins" and so called "partial checkout", or "sparse checkout", or "narrow checkout". scm> <compare> scm> <s id="bazaar">For checkouts: No. For checkins: Yes.</s> scm> <s id="darcs"> scm> It is possible to commit only a certain directory. scm> However, one must check out the entire repository as a scm> whole. scm> </s> scm> <s id="mercurial"> scm> It is possible to commit changes only in a subset of the scm> tree. There are plans for partial checkouts. scm> </s> scm> <s id="monotone"> scm> It is possible to commit changes only in a subset of the scm> tree. However, one must extract the entire tree to work scm> on it. scm> </s> scm> <s id="git"> scm> No. However, commits could be restricted somewhat, scm> see the "Repository Permissions". scm> </s> I think (depending of course on "Repository Permissions" part) that the part about 'work_on_dir' for checkins should be made more clear. Note also that for this criterion, for distributed version control systems, one should consider difference between comitting changes (pre-commit hook), and publishing changes (update and post-receive hook). I would also add that "There are plans for partial checkout" (or rather "sparse" checkouts), where "plans" for this mean "preliminary work". Although implementing this idea seems stalled a bit. I guess that when Git acquires ability to do sparse checkout, it would have it done correctly (c.f. git submodules and svn:externals). scm> <section id="tracking_uncommited_changes"> scm> <title>Tracking Uncommited Changes</title> scm> <expl> scm> Does the software have an ability to track the changes in the scm> working copy that were not yet committed to the repository? scm> </expl> This also should be made more clean. Does it mean for example ability to tell which files have changed, or ability to diff working copy to either last comitted changes, or to any revision available in repository? scm> <compare> scm> <s id="cvs">Yes. Using cvs diff</s> scm> <s id="git"> scm> Yes. "Using git diff"? The problem is with [possible] difference between "git diff", "git diff HEAD", "git diff --cached". scm> scm> Also, branches are very lightweight in Git, and scm> could be considered a kind of storage for "uncommitted" scm> code in some workflows. scm> </s> I'm not sure if it is worth mentioning here _explicit_ staging area (index) available in Git. BTW. it would be nice if "git gui", the Git GUI distributed with Git, had some graphical diff (and diff3) view tool. scm> <section id="per_file_commit_messages"> scm> <title>Per-File Commit Messages</title> scm> <expl> scm> Does the system have a way to assign a per-file commit message scm> to the changeset, as well as a per-changeset message? scm> </expl> scm> <compare> scm> <s id="git">No. Commit messages are per changeset.</s> scm> </compare> scm> </section> scm> </section> O.K. By the way, does anybody know what happened to the 'commit annotations', aka 'notes' idea? scm> <section id="technical_status"> scm> <title>Technical Status</title> scm> <section id="documentation"> scm> <title>Documentation</title> scm> <expl> scm> How well is the system documented? How easy is it to scm> get started using it? scm> </expl> scm> <compare> scm> <s id="git"> scm> Medium. The short help is too terse and obscure. scm> The man pages are extensive, but tend to be confusing. scm> The are many tutorials. scm> </s> scm> </compare> scm> </section> That of course depends on your opinion. I would say "Good", now that there is "Git User's Manual" distributed with Git, and now that there started semi-official "Git Community Book" (http://book.git-scm.com). [Perhaps we could use some survey results do defend that fact.] scm> <section id="ease_of_deployment"> scm> <title>Ease of Deployment</title> scm> <expl> scm> How easy is it to deploy the software? What are scm> the dependencies and how can they be satisfied? scm> </expl> scm> <compare> scm> <s id="git"> scm> Good. Binary packages are available scm> for modern platforms. C compiler and Perl are scm> required. Requires Cygwin on Windows, and has some scm> UNIXisms. scm> </s> scm> </compare> On one hand there are are still a few important Git commands like git-am (for patch+email based workflows), git-bisect, git-pull, git-rebase[1], git-stash and internal parts of git-merge[2] which do require POSIX shell, and what is inherent in shell scripting some core utilities like grep, sed, cat; also for some workflows ssh is needed. This is gets reduced bit by bit due to builtinification efforts. On the other hand thanks to msysGit project Git does not require Cygwin to be installed on MS Windows. I would also remove "has some UNIXisms" which doesn't bring IMVHO any information. [1] This I hope would change thanks to builtin git-sequencer from GSoC (or rather post-GSoC work). [2] This I hope would change thanks to post-GSoC expansion on builtin git-merge scm> <section id="command_set"> scm> <title>Command Set</title> scm> <expl> scm> What is the command set? How compatible is it with scm> the commands of CVS (the current open-source defacto scm> standard)? scm> </expl> Sidenote: I'm not sure if CVS is still "defacto standard"; additionally distributed SCM have enable vastly different workflows, so it is hard to compare their command set to that of CVS, and such comparison covers only subset of DSCM commands. scm> <compare> scm> <s id="subversion"> scm> A CVS-like command set which is easy to get used to scm> for CVS-users. scm> </s> scm> <s id="bitkeeper"> scm> A CVS-like command set with some easy-to-get-used-to scm> complications due to its different way of work and scm> philosophy. scm> </s> scm> <s id="bazaar"> scm> <s id="mercurial"> scm> <s id="monotone"> scm> Tries to follow CVS conventions, but deviates scm> where there is a different design. scm> </s> scm> <s id="perforce"> scm> Very extensive but not compatible with CVS. scm> </s> scm> <s id="git"> scm> Command set is very feature-rich, scm> and not compatible with CVS. scm> </s> I wouldn't say that situation with Git is different from situation with Mercurial, Bazaar-NG and Monotone, especially with respect to subset of commands which have equivalents in CVS. Although Git doesn't "try to follow CVS conventions", it does follow BitKeeper convention, then by transitive also CVS conventions. I would agree with "feature-rich" comment, though ;-) scm> <section id="networking"> scm> <title>Networking Support</title> scm> <expl> scm> How good is the networking integration of the system? scm> How compliant is it with existing protocols and infra-structure? scm> </expl> scm> <compare> scm> <s id="bazaar"> scm> Excellent. Works natively over HTTP (read-only), scm> FTP and SFTP without having Bazaar installed at scm> the remote end. Works over HTTP, SSH and a custom scm> protocol when talking to a remote Bazaar scm> server. Supports RSYNC and WebDAV (experimental) scm> through plugins. scm> </s> scm> <s id="mercurial"> scm> Excellent. Uses HTTP or ssh. Remote access also scm> works safely without locks over read-only network scm> filesystems. scm> </s> scm> <s id="git"> scm> Excellent. Can use native Git protocol, scm> but works over rsync, ssh, HTTP and HTTPS also. scm> </s> It could be written differently, but O.K. scm> <section id="portability"> scm> <title>Portability</title> scm> <expl> scm> How portable is the version-control system to various scm> operating systems, computer architectures, and other scm> types of systems? scm> </expl> scm> <compare> scm> <s id="git"> scm> The client works on most UNIXes, but not on native scm> MS-Windows. The Cygwin build seems to be workable, though. scm> </s> scm> </compare> scm> </section> scm> </section> "Most UNIXes" (or is it Unices)? On what modern UNIX Git doesn't work? Again, the author of of entries for Git doesn't seem to know about msysGit project, which is native MS Windows implementation (utilizing MSYS / MinGW). And what does "Cygwin build _seems_ to be workable" mean? The entry for Git lacks also single word descriptions, like "Excellent", "Very good", "Good", "Medium", that most other SCM have in this part (and "Windows only" for some). scm> <section id="user_interaces"> scm> <title>User Interfaces</title> scm> <section id="web_interface"> scm> <title>Web Interface</title> scm> <expl> scm> Does the system have a WWW-based interface that can be scm> used to browse the tree and the various revisions of the scm> files, perform arbitrary diffs, etc? scm> </expl> scm> <compare> scm> <s id="git"> scm> Yes. Gitweb is included in distribution. scm> </s> scm> </compare> scm> </section> For other SCMs there are listed many different web interfaces. So I would perhaps put here a list, like in http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-e5a6762d6aed31c5a2034d52c1733ead46402c31 (There is slight problem with Gitweb, which has neither homepage nor separate repository; we can use Gitweb page on Git Wiki, or README from git.git repository via gitweb ;-). scm> <section id="availability_of_guis"> scm> <title>Availability of Graphical User-Interfaces.</title> scm> <expl> scm> What is the availability of graphical user-interfaces for scm> the system? How many GUI clients are present for it? scm> </expl> scm> <compare> scm> <s id="git"> scm> Gitk is included in distribution. scm> QGit and Git-gui tools are also available. scm> </s> scm> </compare> scm> </section> scm> </section> git-gui is _also_ included in distribution. So I would say: <s id="git"> Gitk and git-gui are included in distribution. <a href="[1]">Other tools</a> are also available. </s> [1] http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-cee25e252efc24b245482fe9fa8d24ff5d5af1d6 scm> <section id="license"> scm> <title>License</title> scm> <expl> scm> What are the licensing terms for the software? scm> </expl> scm> <compare> scm> <s id="git">GNU GPL v2 (open source).</s> scm> </compare> O.K. -- 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
