"git" vs. "subversion" for Source Code Control

[yesthattom]

My first book was written using CVS (Concurrent Version System) to store the docs and share them with my co-authors. The second edition used SubVersion, which is a much improved replacement.

I keep all my slide presentations related to the book using SubVersion. However, it’s a pain in the butt because it puts a “.svn” directory in every directory. This was fine when I was all PowerPointy, but now that I’m on a Mac and use Keynote, it gets totally confused by having those .svn directories appear within a “package” (Mac docs are really a directory of many little files).

I heard that “git” only creates one .git directory and no more. So I figured I’d give it a try.

Tonight I played around with “git”. It is a different beast than SubVersion. Instead of a central repository, everyone’s machine is a repository. Everyone has their own branches. That way you can branch off, do a little experiment, share it with a friend (it has its own URL) so they can try it, keep it or throw it away, etc. Only when you are sure you want it, do you push it to the main server. This is pretty radical. I hear a lot of developers saying that it is the only way to be working on large source code bases.

Wait, I just said, “main server” but previously I said that everyone’s desktop was a complete server. It’s true. However, you can create a “public server” which lets you have a central place to form a community around. They even have a doc that explains how to use this feature in a subversion-like manner. GIT for SubVersion Users.

Here are some notes I have from my experience:

1. When creating a public repository there is a step where you make a “bare” repository then rsync it to the public place. That didn’t work for me. I kept getting errors about “can’t cd” or something. However, I was able to do all the steps when I kept it all on one machine.

2. Pulling down the software for the first time looks like this: git clone ssh://the.server.com/home/git/project.git/

3. The equiv of “svn update” (to merge in any changes from the server) is: git pull ssh://the.server.com/home/git/proj.git/ master:master master:master (yes, you have to include the URL every time. Ugh.

4. Checking in your files checks them into your local repository. AFTER that, you can push it to the public server with: git push ssh://the.server.com/home/git/proj.git/ master:master (again, the entire URL is required every time. Ugh.)

Any git users have a recommended way to avoid having to type the whole URL every time? I’ve set up unix shell aliases, but there has got to be something better.

I haven’t used it for more than a few hours. So far git seems really nice. I look forward to learning beyond these basic commands.

Comments

[n5red.livejournal.com]

I desperately need to get all the tools and configurations organized for the cluster I am responsible for.

Tom, are you planning any trips through Central Texas? There are a number of professors I would like you to meet.

[kimuchi.livejournal.com]

Distributed revision control is both neat and scary. There was a little talk about moving to git when I first started at Splunk, but the p4 loyalists won out.

I don't have any strong biases in the revision control world but I don't really see subversion as a "much improved" replacement for CVS. It's the stylish new hotness, yes, but it seems to cause equal or greater amount of swearing among RE friends.

URL+refspecs shortcuts (aka "remotes") for git-pull and git-push

[jakub narębski (from livejournal.com)]

You don't need to type whole URL (and refspecs) every time; you can set up "nickname" for URL and refspecs, which is called in git jargon 'remote'.

The easiest way to follow some repository is to use
  git remote add <name> <URL>
where 'name' is your nickname (shortcut) for remote repository, and URL is repository URL. This just set up configuration for remote repository in your '.git/config', see git-remote(1) (http://www.kernel.org/pub/software/scm/git/docs/git-remote.html)

Or you can set up your remote by editing '.git/config' file, adding the following section

[remote "proj"]
     url = ssh://the.server.com/home/git/proj.git/
     fetch = master:master
     push  = master:master

See also git-config(1) (http://www.kernel.org/pub/software/scm/git/docs/git-config.html), section "Configuration file" for description of config file syntax and config variables, and (for example) git-pull(1) (http://www.kernel.org/pub/software/scm/git/docs/git-pull.html), section "Remotes".


BTW its "Subversion", not "SubVersion".

[yesthattom.livejournal.com]

For individual files, I still love RCS. It's just a pain to use. Thus, I use xed (http://www.nightcoder.com/code/xed/) so that I don't have to think about the RCS commands.

There are some good systems for using subversion to maintain all config files in remote repositories. (There are a few... which tells me they are easy to create)

As far as coordinating them all all the servers, that's another story. I favor something like puppet to keep things in sync. Starting with a "golden image", then using something to update the hosts from there.

I don't have Texas in my current travel plans. I'm not currently promoting any books :-)

[yesthattom.livejournal.com]

It's more scary to me than anything else. I really wanted to simply replace Subversion part-for-part. It's a model that everyone is used to. If individuals want to do their own private forks, that's cool but I don't need to know about it. :-)

I wrote that Subversion is much improved over CVS because CVS doesn't handle binary files well (important since book-writing involves a lot of MS-Word and PDFs). It also handles renames better. Aside from that, it still has as many problems as CVS has, just in different areas.

At work I use Perforce with a HUGE wrapper around it to create the workflows we want. I think most developers want these systems to just stay out of their way; they want to check out / edit+build / check in. Everything else is only going to be used by a minority of people.

Re: URL+refspecs shortcuts (aka "remotes") for git-pull and git-push

[yesthattom.livejournal.com]

OMG thanks! I'll try that out and see how it goes.

[polydad.livejournal.com]

This looks like fun; I think I have to go play with it for a bit. My thanks for the tip.

best,

Joel

[ckd]

As a long-time Emacs-head, I generally use VC to handle checkin/checkout for RCS from within the editor. At my last job we had a wrapper script similar to xed, so that the vi users use RCS more easily for the config files also. (It created, if necessary, a directory in /var/rcs and a symlink, so that we could more easily back up all the RCS ,v files for /etc, /usr/local/etc, and wherever else things were living.)

[kimuchi.livejournal.com]

Ah, yeah, binary files aren't really my concern most of the time (and honestly I never expect revision control systems to handle them well).

I'm the minority, obviously, so my concerns are pretty different from most people. But the developers I work with are mostly very sophisticated p4 users as well, which is nice.

[vees.livejournal.com]

I had a need for a DVCS for a simple project and tried to get around git, but failed. Finally wound up trying Mercurial which took a lot of the complexity and weirdness of git away and set up in a few minutes. Maybe if I had had more time/patience I would have figured it out.

Mercurial vs. Git

[jakub narębski (from livejournal.com)]

IMVHO (I am Git user, so this is most probably biased) Mercurial is simpler to use because (besides having good documentation) is simpler. I am talking here about multiple branches in single repository, tracking changes from more than one repository, using tags (to mark releases), merges with more than two parents, dealing with renames, dealing with binary files.

Git is IMHO a very good example of "worse is better" as it wasn't as much developed, as it grown...

Re: Mercurial vs. Git

[vees.livejournal.com]

Yeah, I'm sure this is the case.

Binary files in revision control systems

[jakub narębski (from livejournal.com)]

Ah, yeah, binary files aren't really my concern most of the time (and honestly I never expect revision control systems to handle them well).

There are few problems with binary files, all of them I think solved in git:

• storage - especially for VCS which use delta based storage; git uses binary deltas in packfiles, so it shouldn't be a problem.


• data mangling - for example keyword expansion and CRLF (end of line marker) conversion; here VCS should autodetect if file is binary, and have an option to specify that file is binary. Git by default doesn't do data mangling, but when it does it uses the same binary detection as GNU tools (for example GNU diff) and you can always tell that a file is to be treated as binary file using gitattributes mechanism


• patches and merging - default line based diff and patch, and line based 3-way merge wouldn't work for binary files; Git has mail safe binary patch, if there is merge conflict in binray file it does not resolve it using 3-way merge, but leave conflict in index

Re: Binary files in revision control systems

[awfief.livejournal.com]

See and here I was wondering "why is Tom using a revision control system for a binary file"?

Does it actually help? does it strings and give you the difference or something? Or do you just rely on your own good comments on the checkin?

Re: Binary files in revision control systems

[jakub narębski (from livejournal.com)]

See and here I was wondering "why is Tom using a revision control system for a binary file"?

Sometimes you have to have binary files in a project. Think for example about revision control for source of some web page, which usually includes images... which are binary. And you don't want your VCS to corrupt them, even if you never merge them in any other way than taking one version or the other.

Here is an example of binary diff in Git (which you can send in email, for example). It is creation diff, soe it is not that good example, but nevertheless...

diff --git a/gitweb/git-favicon.png b/gitweb/git-favicon.png
new file mode 100644
index 0000000000000000000000000000000000000000..de637c0608090162a6ce6b51d5f9bfe512cf8bcf
GIT binary patch
literal 164
zcmeAS@N?(olHy`uVBq!ia0vp^0wB!93?!50ihlx9JOMr-t_OgO28RD&a4c8tKak5=
z;1OBOz`!jG!i)^F=12eq?L1u^Ln;_q4{j86a1dcV@b%g0mmUiOK9(+Io+#BK-XURJ
z*52lzAh4o%_q+oa1XgVS7Wa3@eurhH>!fs<8s*Qab3eLq`JX({BnD4cKbLh*2~7aN
C3N}^%

literal 0
HcmV?d00001

Re: Binary files in revision control systems

[yesthattom.livejournal.com]

I write good comments. I rarely, if ever, have had to do an actual binary diff. Mostly I use the repository as a hard drive. I'm working on a tutorial from home, I check it in. When I get to work I think of a change I'd like to make, I check it out, make the change, check it back in.

Perforce...

[rationalfool.livejournal.com]

While I am as much a Free Software bigot as the next person, I cannot get past the simplicity and power of P4. I use the 2 person free license for my private code. And use the P4DTI to integrate it with Bugzilla and with that I have a way to file my TODOs, track them, etc. And it has somewhat decent Mac filetype, resource fork, etc, support.