From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Git's victory and an entertaining irony Date: Sat, 15 Nov 2014 14:13:56 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20141115191356.GA5987@thyrsus.com> References: <20141114183737.GB3168@acm.acm> <5466517B.50705@porkrind.org> <20141114215404.GD3168@acm.acm> <838ujchods.fsf@gnu.org> <8761egx1k2.fsf@uwakimon.sk.tsukuba.ac.jp> <83sihkg2ds.fsf@gnu.org> <87vbmgv3b9.fsf@uwakimon.sk.tsukuba.ac.jp> <834mu0flug.fsf@gnu.org> <87sihkuy6c.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416078893 15836 80.91.229.3 (15 Nov 2014 19:14:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 19:14:53 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 20:14:49 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xpio4-00015Q-Md for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 20:14:48 +0100 Original-Received: from localhost ([::1]:41718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpio4-0003LT-85 for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 14:14:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpinw-0003LB-7M for emacs-devel@gnu.org; Sat, 15 Nov 2014 14:14:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xpinr-0004I7-TB for emacs-devel@gnu.org; Sat, 15 Nov 2014 14:14:40 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:42004 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpinj-0004Gf-02; Sat, 15 Nov 2014 14:14:27 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 447FC382C27; Sat, 15 Nov 2014 14:13:56 -0500 (EST) Content-Disposition: inline In-Reply-To: <87sihkuy6c.fsf@uwakimon.sk.tsukuba.ac.jp> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177233 Archived-At: Stephen J. Turnbull : > As Eric said, "git has won." Heck, even Tom Lord (remember Tom Lord?) > said that git got the basics right, and used the git object database > as the foundation for his new VCS, revc. While I am still of this opinion with respect to changeset-oriented VCSes, something ironically funny happened last week. I wrote a new VCS that violates the crap out of most modern assumptions about VCS design. And it's a success at version 0.8 - has real users and a growing dev community. Yes. That's right. I wrote a VCS. Took me 14 hours to go from concept to shippable, documented 0.1. (Thank you, Python.) Here's why. I noticed something about my work habits. Which is that even though I judge git has won, it's not the only version-control system I use. A significant percentage of my files are maintained in RCS through VC. And there's a reason for this that isn't pure inertia. I have some directories full of single-file projects - FAQs, manuscripts, small shellscripts, that sort of thing (my ~/bin is one of them). I use RCS on these because I want each file to have a version-control history but one that is *separate from the others*. This exactly violates the root assumption of modern VCSes, which designed to manage entire directories (and subdirectories) with joint histories. So I asked myself: what would a VCS *specifically designed for this use case look like*? There are kluges to address it, with unlovely names like "zit" (a wrapper around git), but they all throw away at least one desirable feature of RCS, which is no binary blobs. An RCS file is a textfile (unless you explicitly insert binary data in it). There are fundamental reasons this is a Good Thing which I trust I not have to explain on *this* list. Then I thought: I could wrap RCS in Python, keep the readable history format, and hide all the ugly crap like RCS version numbers and the forty kajillion RCS invocation switches. Then I wrote the manual page. I called it SRC, "Simple Revision Control", an anagram of RCS. I wrote the manual page *first*. I did this because I wanted to think through the user-interface issues without having my thinking distorted by implementation issues and the temptation to take wrong shortcuts. What came out looked like this: 1. Integer revision numbers monotonically increasing a la Subversion. This was the single most important decision - they're great if you have a centralized file store, and RCS's native revision numbering is *nasty*. 2. Lockless operation. Workfiles are, unlike bare RCS, normally writeable. 3. CLI patterned on Subversion and hg. "src checkout " does what you think it does. So does "src commit ", "src log " and "src status". 4. Named tags and branches that work just like you think they should from other systems. A tag is a named synonym for a numbered revision hat can be used in ranges. 5. Two kinds of range literal: M..N follows branch structure, M-N ignores it. 6. Both export and import via fast-import streams. If your project grows up enough to become multi-file, you just push a button... It's deliberately a conservative design with no surprises - the two kinds of range literal are the closest thing to an innovation in the interface. My goal was for it to feel ready to the hand of anyone with prior experience of the major VCSes. My alpha users assure me that I have succeeded in this. Yes, I will write VC support. It's already packaged in the Arch user repository. I have contributions from three devs besides myself. About half a dozen users I know of, probably more I don't. This is day nine of its life. SRC: http://www.catb.org/esr/src/ SRC FAQ: http://www.catb.org/esr/src/FAQ.html And yes. I do think it's funny. -- Eric S. Raymond