From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Robert Anderson Newsgroups: gmane.comp.version-control.arch.user,gmane.emacs.devel Subject: Re: Gud lord! Date: 07 Jun 2003 21:40:58 -0700 Sender: arch-users-admin@lists.fifthvision.net Message-ID: <1055047259.1517.264.camel@lan1> References: <16098.1698.415992.223606@nick.uklinux.net> <1055004206.1439.12.camel@lan1> <20030607210527.GA20914@gnu.org> <1055023668.1517.46.camel@lan1> <20030607234736.GA5741@gnu.org> <1055032089.30724.114.camel@lan1> <20030608020202.GB21024@gnu.org> Reply-To: arch-users@lists.fifthvision.net NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1055046649 24663 80.91.224.249 (8 Jun 2003 04:30:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 8 Jun 2003 04:30:49 +0000 (UTC) Cc: emacs , arch Original-X-From: arch-users-admin@lists.fifthvision.net Sun Jun 08 06:30:47 2003 Return-path: Original-Received: from mail.000domains.com ([64.66.104.205]) by main.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 19OrpP-0006Pe-00 for ; Sun, 08 Jun 2003 06:30:47 +0200 Original-Received: (qmail 23439 invoked from network); 8 Jun 2003 04:33:05 -0000 Original-Received: from mail.000domains.com (64.66.104.205) by mail.000domains.com with SMTP; 8 Jun 2003 04:33:05 -0000 Original-Received: (qmail 22666 invoked from network); 8 Jun 2003 04:32:34 -0000 Original-Received: from pimout1-ext.prodigy.net (207.115.63.77) by mail.000domains.com with SMTP; 8 Jun 2003 04:32:34 -0000 Original-Received: from [192.168.0.2] (adsl-64-163-139-137.dsl.snfc21.pacbell.net [64.163.139.137]) by pimout1-ext.prodigy.net (8.12.9/8.12.3) with ESMTP id h584WUPg080446; Sun, 8 Jun 2003 00:32:30 -0400 Original-To: Miles Bader In-Reply-To: <20030608020202.GB21024@gnu.org> X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Errors-To: arch-users-admin@lists.fifthvision.net X-BeenThere: arch-users@lists.fifthvision.net X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Arch users discussion list. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.comp.version-control.arch.user:201 gmane.emacs.devel:14908 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14908 On Sat, 2003-06-07 at 19:02, Miles Bader wrote: > You're entitled to your opinion of course, but I've seen enough, from people > that I trust, to feel cautious. Cautious is good. But I'm very interested to hear what you've "seen from people you trust." I contribute to arch and I'm always looking for ways to improve it. > Emacs is a fairly mature system, and has muddled along reasonably well with > CVS's brain-damage, so there's little need to make any quick decisions. I think people felt that way about ed before emacs came around. etc. > I'd guess that Emacs will probably switch too at some > point, and probably won't be the last -- but I don't think it should be among > the first. I'd agree with that. I never said "emacs needs arch today." I merely pointed out that stuff like the file renaming handcuffs are removed when using arch. > In fact, I _like_ the idea of switching to something new and cool because I'm > as annoyed by CVS's bogosities as much as anyone (maybe more than most > people -- as I use a slow modem link, and I understand that arch handles > incremental updates much more efficiently than CVS [sending diffs both ways]), For some use cases, it's much better than that, even. If you're ok with, say, daily updates from upstream, you can run a cron job to grab a local mirror overnight, and get fully local disk performance for all daily work. > > They are defined by regexps. I don't think regexps can reasonably be > > considered "murky." > > I think the issue was that this decision was based on names at all. I seem > to recall that there was a way to `register' files as well, but that there > were issues with that as well. No offense, but I'm pretty confident that any objections to the basic architecture here are based on ignorance of what the architecture is, and what it allows. The basic reason being that the entire thing can be made essentially isomorphic to CVS behavior in this area, if that's really what you want, but it also allows much more flexibility and power as well. So it can't really be a step backward, and I'm pretty confident that it's a powerful step forward. There is possibly an issue regarding defaults, but that is much less worrisome than questions about basic architecture or functionality. There's two layers here: the outer layer is based on naming conventions to determine what files are _candidates_ for source, and the inner layer is based on a "tagging method" (which granted, is possibly confusing terminology for a CVS-head) which determines which of those files are versioned. The simplest "tagging method" is the very CVS-like "explicit tagging" - which means you have an "add" operation to version a file in the tree and a "delete" operation to stop versioning a file. So with a "naming convention" of "everything is source" and "explicit tagging," you're essentially looking at a very CVS-like system for determining what files to version. But there's much more to it, and for good reasons that require considerable background and revctl mind-expansion for the typical person coming from a CVS background. Now, regarding this idea of "naming conventions" that people seem to be skeptical of: find me a seasoned programmer who doesn't have a script or alias or some mechanism which is used for finding or grepping through files he's interested in in a source or project tree. I've had "sfind" and "sgrep" and "mktags" (source find/grep, tag source files) scripts for 10 years, which filter out files which I don't want polluting my searches for things in my source tree (say, CVS control files or core files or dot-oh files). This is the spirit of the "naming conventions" in arch. It standardizes and builds this kind of functionality right into the revctl, per-project. Think of naming conventions as a specialized and customizable find command for source trees, because that is exactly the functionality it provides. It's loosely related to the idea of .cvsignore in CVS but much more powerful. > BTW, thank you for posting this, because at the least, it's some impetus to > look more closely at the current state of things. No prob. I don't mean to push, but I think it's important to remind people that alternatives exist when they complain about limitations of their current tools. Bob