Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names.

[Eric S. Raymond]

Juanma Barranquero <address@hidden>:
> On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <address@hidden> wrote:
> 
> > Wouldn't defining emacs-bzr-get-version as an obsolete function alias
> > for emacs-repository-get-version solve the problem in a way
> > satisfactory to both of us?
> 
> Sorry, no. It is not compatible. Code has been written that
> understands the case that emacs-bzr-version isn't bound, or bound and
> nil, or bound and meaningful (with structure). That code will have to
> be changed if you insist in conflating it with your higher-level API
> which IMO is not really a new layer (Emacs is not going to have to
> deal with several underlying DVCS at once in its repository, as you
> said yourself a few messages ago; DVCS-specific functions and
> variables are not only not a bug, but a feature).
> 
> > It wouldn't reintroduce a layering bug into loadup.el, and it would give you
> > your compatible API.
> 
> Even accepting that it is a layering bug (which I don't), there's no
> problem in keeping it in loadup.el; that's why we have
> make-obsolete(-variable). We don't need to clean up in a hurry every
> possible clue of past mistakes; just fix the mistakes. And, as said,
> what you offer is not compatible. emacs-repository-version is not
> compatible with emacs-bzr-version; the structure was documented, it
> never was a magical, opaque cookie.
> 
>     J

The more you talk about this, the less you're making any sense to me.

All this about the return value having structure is a red herring. You
still *get* that structure by looking at emacs-bzr-version.  I have
not changed that and will not; only the VCS transition will do that.

Similarly, the unbound and bound-but-nil cases will still work; that's
the point of declaring an alias, isn't it?

With both the variable and function alias in place, I don't understand
what code would need to be changed.  Show me.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>