From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jim Blandy" Newsgroups: gmane.emacs.devel Subject: Switching to Subversion Date: Tue, 14 Nov 2006 12:16:54 -0800 Message-ID: <8f2776cb0611141216y4a8384fdjfefc2fa846e0f811@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1163536301 27472 80.91.229.2 (14 Nov 2006 20:31:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Nov 2006 20:31:41 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 14 21:31:38 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gk4wN-000865-Tg for ged-emacs-devel@m.gmane.org; Tue, 14 Nov 2006 21:31:32 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gk4wM-0004eg-Lw for ged-emacs-devel@m.gmane.org; Tue, 14 Nov 2006 15:31:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gk4iI-0005XI-87 for emacs-devel@gnu.org; Tue, 14 Nov 2006 15:16:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gk4iG-0005Wr-M5 for emacs-devel@gnu.org; Tue, 14 Nov 2006 15:16:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gk4iG-0005Wo-HP for emacs-devel@gnu.org; Tue, 14 Nov 2006 15:16:56 -0500 Original-Received: from [64.233.182.191] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gk4iG-0005gp-T5 for emacs-devel@gnu.org; Tue, 14 Nov 2006 15:16:57 -0500 Original-Received: by nf-out-0910.google.com with SMTP id n15so375155nfc for ; Tue, 14 Nov 2006 12:16:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=cFbzgtuW2lgGf5lOWBFbH+cEeR43u2/mx92QFbjvHhoNFlONdUI2M6emYqh4yaXcrIpBVvnuB8jhR1ff4UyUK3aes4+9su/DFOO6cRItEN9twToZAdmM0AfaUY8mGOIQfD36na7PRKG3e/oDz25WD7/xIVYAFi0cmiHdbHBvB/8= Original-Received: by 10.82.105.13 with SMTP id d13mr187123buc.1163535414102; Tue, 14 Nov 2006 12:16:54 -0800 (PST) Original-Received: by 10.82.145.6 with HTTP; Tue, 14 Nov 2006 12:16:54 -0800 (PST) Original-To: emacs-devel@gnu.org Content-Disposition: inline X-Google-Sender-Auth: d56befc438468c52 X-Mailman-Approved-At: Tue, 14 Nov 2006 15:31:04 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:62307 Archived-At: I designed the Subversion repository structure, and began the work on the first filesystem implementation, so I can answer some of the "what were they thinking?" questions that have come up on this thread. We were aware from the beginning of the importance of merging. We had long discussions on what merging should mean, and the fellow who handles version control for HP's inkjet printer division (they use a big changeset engine) came to talk to us about changesets. We all agreed that changeset-based systems with interfaces like Darcs and BitKeeper were The Right Thing, and the most useful way to think about the whole activity of collaborative development. However, we didn't implement that because we couldn't see any way to do it in a way that scales to very old repositories. For example, the GCC repository has 118807 revisions in it at the moment, and handles them just fine. I don't see how a system with a repository structure like Darcs (which I use and absolutely love) is going to handle that, unless you're willing to rearrange your repository to trade speed for historic detail. And there have been comments from Larry McVoy to the effect of, "big deal, everyone falls down with a few tens of thousands of revisions". Subversion has demonstrated that that's not so. >>From discussions with other people who follow these things more closely, I understand that Mercurial has an excellent repository structure: very compact, very fast, and very versatile. The Subversion project has plans --- which should be weighed as just that, plans and talk --- to incorporate some of Mercurial's characteristics in its merge support. I do occasionally see a tendency in programming circles for people who have recognized others' good ideas to adopt the strut earned by the person who actually had them. It always looks a little strange.