ESS 12.04 --- VERSION / ess-custom.el <-> ess-revision still brittle

[Martin Maechler]

On Fri, Apr 6, 2012 at 14:13, Vitalie Spinu <spinuvit at gmail.com> wrote:
>>>>> Martin Maechler <maechler at stat.math.ethz.ch>
>>>>> on Fri, 6 Apr 2012 02:20:59 +0200 wrote:
>
>  > HOWEVER, if you remove the *.elc and then build from the
>  > tarball, then 'svn up' is tried to be used for building VERSION
>  > and  lisp/ess-custom.el
>  > and it does destroy the correct ess-revision and replace it by a
>  > pseudo one ("12.04-rexported") for me.
>
> I've realized only now what the change was about. Make is now messing
> with ess-custom.el. This could not be right. I cannot use git properly
> anymore, as gitsvn would not allow me to fetch new revisions unless I
> have all my changes stashed or committed. So each time, after make, and
> before fetching I have to do "git reset HEAD --hard" to undo the make
> change.
>
> For SVN users: assume X committed his ess-custom.el, and Y (having his
> own change in ess-custom.el) is updating. Then Y will get an unmerged
> conflict, right?

yes, possibly.
I agree that *committing*  ess-custom.el  after practically every change to ESS
is clearly "wrong".
Rather, the "ess-revision" should not be stored in *.el
but in a toplevel (as opposed to ./lisp/ ) file, say  SVN-REVISION  --
analogous to the current VERSION -- which is *NOT* part of svn, but is
auto-regenerated by make
and is part of the "downloads" make target and hence part of every
*tar / *zip distribution.
We can really learn from R  here.
Consequently, on startup, ESS reads that file and populates the ess-revision ...
(and do that in a fail-safe way so that ess-revision may be "unknown"
when SVN-REVISION does not exist or is so wrong it cannot be safely
read).
So people refusing to run make will not get real problems (but remain
to keep a suboptimal output from M-x ess-version).

I should get time implementing this after the Easter holiday.

As Rodney says, we now have a bit of time for "tinkering".
Martin