all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: `smoothing_enabled' undeclared
Date: Mon, 03 Jul 2006 08:33:24 +0900	[thread overview]
Message-ID: <87bqs7shtn.fsf@catnip.gol.com> (raw)
In-Reply-To: <17576.19960.559626.543027@kahikatea.snap.net.nz> (Nick Roberts's message of "Mon, 3 Jul 2006 10:51:36 +1200")

Nick Roberts <nickrob@snap.net.nz> writes:
>  > Every branch has a "head".  The main branch is called "the trunk".
>
> HEAD is a tag.  Is it a tag for the head of the trunk or the head of the
> branch which the working directory is in?

The CVS docs are maddeningly vague about this...

I thought it was the latter, but I just did a bit of testing, and the
result of using -rHEAD is different depending on which command you use.

E.g., if, in a working directory where everything has the sticky tag
"emacs-unicode-2" (i.e., that's the current branch), then if I test on
the file "src/xfaces.c", which is different in the trunk and on the
branch, the following commands yield these results:

   * "cvs diff -rHEAD src/xfaces.c" produces no output -- so presumably
     it's diffing against the latest revision of _the current branch_.

   * "cvs update -rHEAD src/xfaces.c" _changes_ the sticky tag from the
     file to be "HEAD", and updates it to be the latest revision on _the trunk_.

I don't know if I'm missing something, but this seems like pretty dumb
behavior... no wonder people are confused about what HEAD means.

[I suppose the reason it is this way is that they simply didn't
special-case HEAD in places where they really should have, so the result
is probably internally consistent but confusing for users...]

So I think that you shouldn't use "-rHEAD" with any command that would
set the sticky tag when given a real branch tag name, but it should be
OK when used with commands like diff.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

  reply	other threads:[~2006-07-02 23:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-23  3:20 `smoothing_enabled' undeclared Herbert Euler
2006-06-23 10:10 ` Eli Zaretskii
2006-06-24  2:16   ` Herbert Euler
2006-06-24  2:38     ` Nick Roberts
2006-07-02 16:13       ` Stefan Monnier
2006-07-02 22:51         ` Nick Roberts
2006-07-02 23:33           ` Miles Bader [this message]
2006-07-03 15:40             ` Bob Rogers
2006-07-06 22:27             ` Stefan Monnier
2006-06-24  6:27     ` Eli Zaretskii

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=87bqs7shtn.fsf@catnip.gol.com \
    --to=miles@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.