all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Eric S. Raymond" <esr@thyrsus.com>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: Bastien <bzg@gnu.org>, Emacs developers <emacs-devel@gnu.org>
Subject: Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names.
Date: Thu, 9 Jan 2014 00:27:05 -0500	[thread overview]
Message-ID: <20140109052705.GA3424@thyrsus.com> (raw)
In-Reply-To: <CAAeL0SQA95CrWMvJoj_qOZZ1nKR3BQALMtEF47uzF6NKJJJ2EA@mail.gmail.com>

Juanma Barranquero <lekktu@gmail.com>:
> On second thought, I'm not so sure that renaming emacs-bzr-version and
> emacs-bzr-get-version is a good idea
>
> The reason is that emacs-repository-version and
> emacs-repository-get-version won't be true replacements for the
> current variable and function. They won't contain or return data in
> the same format, and I won't be able, for example, to just use
> emacs-repository-version in the same way I'm using emacs-bzr-version
> right now.

That's true, but it has nothing to do with how the function and 
vaeriable are named and cannot be fixed by changing the name back
or twinning the function.

If you look at emacs-repository-version, it now returns exactly what
you're used to with the bzr local revision number up front.  When we change
over to git, there won't be a local revision number because there is
no such entity in the git universe.  This can't be fixed by anything
in the way our LISP is named or factored.

> It's not possible, because I'm using the fact that their
> value started with a numerical revno (I'm doing arithmetic with that
> value), which does not make sense in Git. I will be forced to change
> my code, so just making emacs-bzr-version into an obsolete alias of
> emacs-repository-version is misleading.

You're making a good case for removing the obsolete alias. But...

> IMO it would make more sense to define new emacs-git-version and
> emacs-git-get-version instances and let user code sort which one needs
> to use.

It might, if we were going to use two VCSes in parallel. That's not
the case.  Where the rubber meets the road is: What should emacs-bug call to
get a build version to report? There can be only one...

>  These function and variable are never going to be really
> repository- or DVCS-independent anyway.

The implementation, no. But the behavior "return a unique magic cookie
that identifies the build" is DVCS-independent.  You're feeling pain 
because you want the magic cookie to have substructure, and *that*
can't be guaranteed across VCSes.  But reverting my renames wouldn't
solve that problem either.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



  reply	other threads:[~2014-01-09  5:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1W124t-0007MM-P3@vcs.savannah.gnu.org>
2014-01-08 23:18 ` trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names Glenn Morris
2014-01-08 23:34   ` Eric S. Raymond
2014-01-08 23:57     ` Juanma Barranquero
2014-01-09  0:04       ` Eric S. Raymond
2014-01-09  0:06         ` Daniel Colascione
2014-01-09  0:12           ` Eric S. Raymond
2014-01-09  0:13             ` Daniel Colascione
2014-01-09  0:09         ` Bastien
2014-01-09  0:27           ` Eric S. Raymond
2014-01-09  0:43             ` Juanma Barranquero
2014-01-09  1:25               ` Eric S. Raymond
2014-01-09  1:31                 ` Juanma Barranquero
2014-01-09  2:13                   ` Juanma Barranquero
2014-01-09  5:27                     ` Eric S. Raymond [this message]
2014-01-09  9:36                       ` Juanma Barranquero
2014-01-09 12:37                         ` Eric S. Raymond
2014-01-09 12:48                           ` Juanma Barranquero
2014-01-09 13:13                             ` Eric S. Raymond
2014-01-09 13:27                               ` Juanma Barranquero
2014-01-09 13:47                                 ` Eric S. Raymond
2014-01-09 14:05                                   ` Juanma Barranquero
2014-01-09 14:29                                     ` Eric S. Raymond
2014-01-09 14:45                                       ` Juanma Barranquero
2014-01-09 15:08                                         ` Eric S. Raymond
2014-01-09 15:21                                           ` Juanma Barranquero
2014-01-09 20:43                                             ` chad
2014-01-09 12:00                       ` Rüdiger Sonderfeld
2014-01-09 12:12                         ` Juanma Barranquero
2014-01-09 12:20                           ` Rüdiger Sonderfeld
2014-01-09 12:24                             ` Juanma Barranquero
2014-01-09  0:10         ` Juanma Barranquero
2014-01-09  3:48           ` Stephen J. Turnbull
2014-01-09  0:34     ` Glenn Morris
2014-01-09  6:36       ` 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=20140109052705.GA3424@thyrsus.com \
    --to=esr@thyrsus.com \
    --cc=bzg@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=lekktu@gmail.com \
    /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.