[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r115926: In preparation for the move to git, sanitize out some

From: Eric S. Raymond
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
User-agent: Mutt/1.5.21 (2010-09-15)

Juanma Barranquero <address@hidden>:
> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]