git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Adding Git to Better SCM Initiative : Comparison
Date: Thu, 29 Nov 2007 02:48:22 +0100	[thread overview]
Message-ID: <200711290248.23239.robin.rosenberg.lists@dewire.com> (raw)
In-Reply-To: <200711282339.59938.jnareb@gmail.com>

onsdag 28 november 2007 skrev Jakub Narebski:
> I'd like to add Git to comparison table of SCMs at Better SCM
> Initiative site:
>   http://better-scm.berlios.de
> 
> To do that, I need to fill in infomration about Git.  Most
> of questions / items didn't give much problem, but there
> are a few on which I would like your input.
> 
> (Yes, I know that such SCM comparisons are usually biased towards the
> idea of what are most important features of a version control system.
> Nevertheless...)
[...]
> 4. Repository Permissions
> 
>    Is it possible to define permissions on access to different
>    parts of a remote repository? Or is access open for all?
> 
> "Partial (?). It is possible to lock down repository
>  (access to branches and tags) using hooks."
> 
> I don't know if it is possible to do finer level ACLs, i.e. if it
> is possible to lock subdirectories or files in Git.  Although for
> distributed SCMs ACL doesn't matter much: check diffstat and merge or
> not from trusted people.  We have "network of trust" (BTW. Karl Fogel
> in OSSBook recommends 'soft' control of access control to repository,
> on social rather than on technical level).

I think what is most interesting here is access to content for which git has
just about nothing worth mentioning, Just admit it. "Truth in advertising".

I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion
of "atomic" again with the author. I did complain a little but nothing happened. The issue is
that Clearcase is listed as having "atomic" commits which is not true for any usable definition
of atomic in SCM context. With the definition in use there I think CVS should be considered
having atomic commits too, at least I've never seen a half-committed file there.

% svn diff
Index: src/comparison/scm-comparison.xml
===================================================================
--- src/comparison/scm-comparison.xml	(revision 290)
+++ src/comparison/scm-comparison.xml	(arbetskopia)
@@ -71,6 +71,9 @@
             <impl id="ls-sync">
                 <name>LibreSource Synchronizer</name>
             </impl>
+            <impl id="git">
+                <name>Git</name>
+            </impl>
         </implementations>
         <timestamp>
             $Id$
@@ -182,6 +185,13 @@
                     needs to be up-to-date before doing a rename/move operation. 
                     This operation will be committed directly.
                 </s>
+                <s id="git">
+                    Yes (or no depending on interpretation). Git typically detects
+		    renames and copies based on content regardless of whether the
+		    committer indicated the fact. The detection is content based
+		    rather than file-id based. There is explicit rename too, but
+		    it is not used much.
+                </s>
            </compare>
         </section>
         <section id="copy">
@@ -236,6 +246,10 @@
                   limitations in Windows environments)
                 </s>
                 <s id="ls-sync">No, copies will start there own history.</s>
+                <s id="git">Yes(or no depending on interpretation). Git detects
+			copies and moves based on content. It does not track
+			history on a file-id based scheme.
+                </s>
            </compare>
         </section>
         <section id="repos_clone">
@@ -288,6 +302,11 @@
                   Yes, but is not documented and its based on the dataflow feature of the
                   LibreSource Synchronizer.
                 </s>
+                <s id="git">
+                  Yes. This is a fundamental part of using Git. A Git user typically always
+		  has a full copy of the entire repostory (well compressed) that is initialized
+		  using a clone command.
+                </s>
             </compare>
         </section>
         <section id="push">
@@ -331,6 +350,7 @@
                 <s id="cmsynergy">Yes, as long as you have the (more expensive) Distributed package.</s>
                 <s id="clearcase">Yes, using Clearcase Multisite.</s>
                 <s id="ls-sync">Yes, it's what we call a dataflow.</s>
+                <s id="git">Yes. This is a fundamental part of using Git.</s>
             </compare>
         </section>
         <section id="permissions">
@@ -417,7 +437,8 @@
                   multi-platform environments.
                 </s>
                 <s id="ls-sync">Permissions are set for the whole repository or branch.</s>
-            </compare>
+                <s id="git">No, but bad changes can be reverted before they are published.</s>
+	</compare>
         </section>
         <section id="changesets">
             <title>Changesets' Support</title>
@@ -490,6 +511,11 @@
                   Partial support. There are implicit changeset that are generated on
                   each commit.
                 </s>
+            	<s id="git">Yes. Actually Git is snapshot based which means Git records
+			the full state in every commit, which means that any two
+			commits can be compared directly very quickly, although the
+			repository is typically browsed as a series of change sets.
+                </s>
            </compare>
         </section>
         <section id="annotate">
@@ -534,6 +560,9 @@
                     Yes locally without any server connection with the standard graphical
                     Java client.
                 </s>
+            	<s id="git">Yes. It can also detect the origin of copied and moved source
+			lines.
+                </s>
            </compare>
         </section>
     </section>
@@ -610,6 +639,12 @@
                    It is possible to commit only a certain directory. However, one must
                    check out the entire repository as a whole.
                 </s>
+            	<s id="git">No. However it is possible to commit only selected 
+			changes in the working tree rather than everything. Subproject
+			support makes it possible to split large projects into several
+			repositories and link them. Related repositories need not be
+			checked out or cloned.
+                </s>
            </compare>
         </section>
         <section id="tracking_uncommited_changes">
@@ -659,6 +694,10 @@
                   Yes, with the Synchronizer Studio (default Java client) or with the
                   standard diff command (diff -r . .so6/xxx/REFCOPY/)
                 </s>
+            	<s id="git">Yes. In addition commits are local and will not be seen
+			until he/she decides to publish them making it possible to
+			track multiple versions locally before publishing.
+                </s>
             </compare>
         </section>
         <section id="per_file_commit_messages">
@@ -714,6 +753,7 @@
                   for a per-changeset message.
                 </s>
                 <s id="ls-sync">No. Commit messages are per changeset.</s>
+                <s id="git">No. The same message applies the the commit as a whole.</s>
            </compare>
         </section>
     </section>
@@ -828,6 +868,11 @@
                   documentation. Installing and getting started with the GUI is very easy
                   though. (update/commit-next-next-next-finished)
                 </s>
+            	<s id="git">
+		  There a good tutorials manual pages and a supportive community.
+		  Basic usage is simple, but advanced usage requires understanding of
+		  what makes git different.
+                </s>
             </compare>
         </section>
         <section id="ease_of_deployment">
@@ -950,6 +995,10 @@
                   LibreSource repository web page. 
                   (links: create workspace, update, commit, studio...)
                 </s>
+            	<s id="git">
+		  Very simple to deploy on Unix-like systems. Windows installs
+		  is not fully developed yet. Installing in cygwin is simple though.
+                </s>
            </compare>
         </section>
         <section id="command_set">
@@ -1048,6 +1097,13 @@
                   Basic commands available (commit/update), but it's really simple to
                   use the GUI. Ant task are also available.
                 </s>
+            	<s id="git">Basic usage could be considered similar, but trying
+			to use Git like CVS would be counterproductive since many
+			cases of CVS usage is by design not possible in Git. The
+			number of command is large. ~140 but only ~20 commands
+			are typically used and less than ten will do for casual
+			users.
+                </s>
            </compare>
         </section>
         <section id="networking">
@@ -1152,6 +1208,13 @@
                 <s id="ls-sync">
                   Good. Use of HTTP to get through firwalls. 
                 </s>
+            	<s id="git">
+		  Excellent. Normal usage is off-line, but networking is
+		  used for sharing changes Networking including ssh, 
+		  a special git protocol http and mail can be used to share
+		  changes, both incoming and outgoing. Mail can be used
+		  via IMAP and mbox files.
+                </s>
             </compare>
         </section>
         <section id="portability">
@@ -1249,6 +1312,11 @@
                   Excellent. Clients and servers work on any Java 1.5-compatible
                   platform. (Windows, Linux and Mac OS X )
                 </s>
+            	<s id="git">
+		  Very good for POSIX compatible environments. A non-cygwin
+		  port for windows is underway. There are some graphical
+		  tools available for windows in cygwin.
+                </s>
             </compare>
         </section>
     </section>
@@ -1323,6 +1391,7 @@
                   Yes, without diff features but with a better awareness support.
                   (allow to know at any time on each version each one is working on) 
                 </s>
+                <s id="git">Yes. gitweb</s>
             </compare>
         </section>
         <section id="availability_of_guis">
@@ -1421,6 +1490,10 @@
                   is automatically launched from the repository web page and 
                   another one which is an Eclipse plugin.
                 </s>
+                <s id="git">
+		  A number of good GUI's are availble for basic usage, 
+		  but typical usage is command based.
+                </s>
            </compare>
         </section>
     </section>
@@ -1501,7 +1574,8 @@
               additional licensing.
             </s>
             <s id="ls-sync">QPL - The Qt Public License (OpenSource)</s>
-        </compare>
+            <s id="git">GPL</s>
+       </compare>
     </section>
 </section>
     </contents>


-- robin

  reply	other threads:[~2007-11-29  1:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28 22:39 Adding Git to Better SCM Initiative : Comparison Jakub Narebski
2007-11-29  1:48 ` Robin Rosenberg [this message]
2007-11-29  7:17   ` Jan Hudec
2007-11-29  2:26 ` Jakub Narebski
2007-11-29 20:07   ` Alex Riesen
2007-11-30  0:18     ` Jakub Narebski
2007-11-30  1:26       ` Johan Herland
2007-11-30  1:53         ` Jakub Narebski
2007-11-30  7:16       ` Alex Riesen
2007-11-30 18:34     ` Jan Hudec
2007-12-03 19:57 ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2007-12-10 12:57 Jakub Narebski
2007-12-10 13:09 ` Eyvind Bernhardsen
2007-12-10 13:20   ` Jakub Narebski
2007-12-10 14:33 ` David Kastrup
2007-12-10 14:49 ` Florian Weimer
2007-12-10 15:23   ` Johannes Schindelin
2007-12-10 15:36     ` Florian Weimer
2007-12-10 15:47   ` Jakub Narebski
2007-12-10 16:28     ` Florian Weimer
2007-12-10 16:38   ` Linus Torvalds
2007-12-10 16:50   ` Chris Shoemaker
2007-12-10 17:21     ` Jakub Narebski
     [not found] ` <200801071057.27710.shlomif@iglu.org.il>
2008-01-13  0:44   ` Jakub Narebski
2008-01-14  0:14     ` Dmitry Potapov
2008-01-14  0:31       ` Jakub Narebski
2008-01-14  6:58         ` Dmitry Potapov
2008-01-14 12:14           ` Jakub Narebski
2008-01-13 15:05 linux
2008-01-13 15:16 ` Matthieu Moy
2008-01-13 16:25   ` Jakub Narebski
2008-01-13 18:42   ` linux
2008-01-13 19:20     ` linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200711290248.23239.robin.rosenberg.lists@dewire.com \
    --to=robin.rosenberg.lists@dewire.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).