Re: migrating from SVN to Git

On 03/03/13 03:14, Matthew Fluet wrote:
> Anyways, I'm looking for feedback on the decision to migrate to Git...

Although I'm not a developer of MLton, I thought I would comment to 
endorse this decision.  I found Git a huge improvement over Subversion, 
even for projects where I am the only developer and the repo exists 
solely on my local machine!

When I worked on a Subversion project, I eventually found myself using 
Git via the git-svn interface.  The main reason was that I often break 
down the implementation of a new feature into a series of ideal changes 
[1] and Git supports this very well: it allows a patch series to be 
prepared privately.  This was a nightmare with Subversion: preparing a 
series of working copies, making sure each contained all the previous 
changes...  The other reason was that 'svn log' (and other commands) 
require access to the repo.  This was irritating with remote repos because
   - I often use a laptop with no internet access (from a train)
   - one project was behind an 'air wall', so the repository was 
accessible only from a particular physical location (but that's an 
unusual situation).

The usual criticism of DVCSs is about carrying around the whole 
repository but I actually want to do that (see above) and it's hardly a 
huge overhead [2].

I consider the main criticism of Git to be its complexity.  If users are 
sufficiently competent, that's not an issue.

Phil



[1] In my opinion, a revision history is vastly more useful if changes 
are presented in a way that makes it easy to
   - understand what has changed and
   - reuse them across development branches.
For example, changes should be logically grouped.  A revision history is 
surely not about capturing the series of changes that actually occurred 
when privately implementing a new feature.  It should be an ideal series 
of changes that typically involves some iteration.  For example, I don't 
want to expose my mistakes to others, not for reasons of pride but 
because I don't want to waste their time by confusing them with mistakes 
that I correct in later changes.  (Who reads out the first draft of a 
speech or prints the first draft of a book?!)  So, for me, the main 
problem with Subversion was the inability to change what has been 
committed.  (Sensibly, once a commit is made public it cannot be changed 
but, due to the centralized nature of a Subversion repository, all 
commits must be assumed public.)

[2] Excluding archived branches:

[pclayton@rizzo git]$ time git clone https://github.com/MLton/mlton.git
Cloning into 'mlton'...
remote: Counting objects: 64431, done.
remote: Compressing objects: 100% (12324/12324), done.
remote: Total 64431 (delta 51794), reused 64079 (delta 51519)
Receiving objects: 100% (64431/64431), 31.41 MiB | 688 KiB/s, done.
Resolving deltas: 100% (51794/51794), done.

real	0m57.359s
user	0m5.113s
sys	0m1.744s
[pclayton@rizzo git]$ time git clone https://github.com/MLton/mltonlib.git
Cloning into 'mltonlib'...
remote: Counting objects: 14343, done.
remote: Compressing objects: 100% (4966/4966), done.
remote: Total 14343 (delta 7434), reused 14343 (delta 7434)
Receiving objects: 100% (14343/14343), 1.96 MiB | 615 KiB/s, done.
Resolving deltas: 100% (7434/7434), done.

real	0m6.226s
user	0m0.481s
sys	0m0.251s
[pclayton@rizzo git]$ du -sm *
69	mlton
9	mltonlib
[pclayton@rizzo git]$

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev