all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Chong Yidong <cyd@stupidchicken.com>,
	Andreas Schwab <schwab@linux-m68k.org>,
	emacs-devel@gnu.org
Subject: Re: Emacs 23.1.90 pretest
Date: Thu, 10 Dec 2009 11:33:54 +0900	[thread overview]
Message-ID: <87r5r3r20d.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <jwvws0vacng.fsf-monnier+emacs@gnu.org>

Stefan Monnier writes:

 > Here's how the scenario I have in mind:
 > 
 >    cvs update
 >    ...blabla build, glance at it, try it out, maybe make a tarball of it...
 >    cvs tag
 >
 > In what way can this be inconsistent with "the One True Repository"?

As you know, CVS commits are not atomic.  You are both wrong when you
write of "One True Repository."  In CVS you simply cannot have a True
Repository in the sense of "true to the Emacs we want to build for
ourselves and distribute to others" without restricting commits to one
developer at a time.

 > In what way is this going to be inconsistent with a checkout by date?

I don't know about your release process, but mine involves testing,
then bumping the version number in configure.ac and version.sh.in, and
putting a release herald in the ChangeLogs, then tagging.  If this
happens:

    cvs update
    ... I build build, test, bump
    ... concurrently, Stefan commits
    cvs commit <exactly the version bump changes, assume no conflicts>
    cvs tag

then the tag spans in time, but does not include, your commit, and in
that sense is inconsistent with checkout by date.

Andreas's procedure using rtag is prohibitively inconvenient, IMO,
because it involves either tagging an untested version or analysis of
changes by others *and* a full test run *after* the tag is created.
If using tag is "inconsistent with a dVCS world", well, what else is
new?

The right way to handle this in CVS IMO is to use "tag", accept the
date/tag inconsistencies for prereleases, and to prohibit commits by
anyone but the release engineer from "cvs update" to "cvs tag" for
public releases.  In that case cvs tag is almost equivalent to cvs
rtag (at least in some versions of CVS there were anomolies having to
do with files that don't exist on the branch being tagged).

Again IMO CVS checkouts by date are only useful for bisection, usually
result in identifying a unique commit, and even if the best you can do
is isolate to a period of say 1 hour with a half-dozen commits, that's
not going to be any worse than (say) bisecting and coming up with the
multi-tty merge as the culprit.  You take a diff and start bisecting
by hunks rather than by time.





  parent reply	other threads:[~2009-12-10  2:33 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09  2:54 Emacs 23.1.90 pretest Chong Yidong
2009-12-09  4:39 ` Juanma Barranquero
2009-12-09 11:33   ` Eli Zaretskii
2009-12-09 12:46     ` Juanma Barranquero
2009-12-09 20:46       ` Chong Yidong
2009-12-09 20:50         ` Juanma Barranquero
2009-12-09 21:00           ` Chong Yidong
2009-12-09 21:08             ` Glenn Morris
2009-12-09 21:45               ` Chong Yidong
2009-12-10  0:45                 ` Juanma Barranquero
2009-12-11 16:48                   ` Chong Yidong
2009-12-11 16:58                     ` Juanma Barranquero
2009-12-09  9:14 ` Giovanni Lanzani
2009-12-09 17:14   ` Jan Djärv
     [not found]     ` <95bd41770912090936x26bdf529n4f54ce42729c8876@mail.gmail.com>
2009-12-09 18:20       ` Jan Djärv
2009-12-09 18:35         ` Giovanni Lanzani
2009-12-09 18:47           ` Jan Djärv
2009-12-10  7:49             ` Yavor Doganov
2009-12-10 19:28               ` Jan Djärv
2009-12-10 19:50                 ` Yavor Doganov
2009-12-10 21:40                   ` Jan Djärv
2009-12-10 23:02                     ` Yavor Doganov
2009-12-11 17:15                       ` Chong Yidong
2009-12-11 20:07                         ` Jan Djärv
2009-12-11 21:36                           ` Yavor Doganov
2009-12-11 21:56                             ` chad
2009-12-11 22:04                             ` Jan Djärv
2009-12-11 23:27                               ` Yavor Doganov
2009-12-12  0:00                         ` David Reitter
2009-12-12  2:32                           ` Chming
2009-12-11 17:19             ` Chong Yidong
2009-12-11 20:05               ` Jan Djärv
2009-12-12  8:10                 ` Jan Djärv
2009-12-09 12:11 ` Andreas Schwab
2009-12-09 14:35   ` Chong Yidong
2009-12-09 15:48     ` Andreas Schwab
2009-12-09 18:52       ` Stefan Monnier
2009-12-09 20:07         ` Andreas Schwab
2009-12-09 21:18           ` Stefan Monnier
2009-12-09 21:45             ` Andreas Schwab
2009-12-09 21:56               ` Stefan Monnier
2009-12-09 23:14                 ` Andreas Schwab
2009-12-10  0:39                   ` Stefan Monnier
2009-12-10  0:45                     ` Andreas Schwab
2009-12-10  2:33                     ` Stephen J. Turnbull [this message]
2009-12-10  9:41                       ` David Kastrup
2009-12-10 12:32                         ` Stephen J. Turnbull
2009-12-09 18:39 ` Steven Knight
2009-12-09 18:56   ` Jan Djärv
2009-12-09 19:21     ` Steven Knight
2009-12-09 20:44       ` Jan Djärv
2009-12-09 21:20         ` Steven Knight
2009-12-11  7:47           ` Jan D.
2009-12-11 14:50             ` Steven Knight
2009-12-11 15:03               ` Jan D.
2009-12-12 16:20               ` Jan Djärv
2009-12-14 23:48                 ` Steven Knight
2009-12-09 19:01 ` David Robinow
2009-12-09 20:17   ` Chong Yidong
2009-12-14  4:59 ` Juanma Barranquero
2009-12-14 16:03   ` Chong Yidong
2009-12-14 16:20     ` Chong Yidong
2009-12-18  5:27 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r5r3r20d.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=turnbull@sk.tsukuba.ac.jp \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.