[Rd] small issue with over-zealous clean.

[Hin-Tak Leung]

--- On Mon, 10/12/12, Martin Maechler <maechler at stat.math.ethz.ch> wrote:

> >>>>> Hin-Tak Leung
> <htl10 at users.sourceforge.net>
> >>>>>     on Mon, 10 Dec
> 2012 09:23:14 +0000 writes:
> 
>     > --- On Mon, 10/12/12, Martin Maechler
> <maechler at stat.math.ethz.ch>
> wrote:
>  [.....]
> 
>     >> > That said ..a small bug was
> introduced back in
>     >> May  .....
>     >> 
>     >> Yes, you are right.
>     >> BTW: The reason that nobody (from R
> core, probably not many
>     >> people otherwise) has found/mentioned
> this bug before is not
>     >> the
>     >> use of svn, but the fact that it is
> much more convenient
>     >> (and
>     >> hence somewhat recommended) to build
> R outside of its
>     >> source
>     >> directory, and in that case the two
> *.Rd files that belong
>     >> to
>     >> ./tests/ are not removed (from the
> *build* directory's
>     >> ./tests/)
> 
>     > "more convenient" is a subjective
> matter.
> 
>     > As I mentioned in my original post, I
> have a few local modifications which are continually
> re-applied ("rebase"d, but I shall not be drawn into arguing
> about matters of personal preference again) - therefore it
> is more convenient to build on top.
> 
>     > Since we are on the topic of
> locally-continually applied modifications, I reported
> another issue about 40 days ago, that reccent R trunk now
> treat revision as numeric, so 'unknown' in the topic level
> Makefile.in should be changed accordingly to 0 or some
> number. Here is the diff - one of the "locally-continually
> applied modifications" I am talking about:
> 
>     > --- a/Makefile.in
>     > +++ b/Makefile.in
>     > @@ -94,7 +94,7 @@ svnonly:
>     > @if test ! -f "$(srcdir)/doc/FAQ" || test
> -f non-tarball ; then \
>     > (cd doc/manual && $(MAKE)
> front-matter html-non-svn) ; \
>     > touch non-tarball ; \
>     > -     
>    (cd $(srcdir); LC_ALL=C TZ=GMT svn info ||
> $(ECHO) "Revision: unknown") 2> /dev/null \
>     > +     
>    (cd $(srcdir); LC_ALL=C TZ=GMT svn info ||
> $(ECHO) "Revision: 0") 2> /dev/null \
>     > | sed -n -e '/^Revision/p' -e '/^Last
> Changed Date/'p \
>     > | cut -d' ' -f1,2,3,4 >
> SVN-REVISION-tmp ; \
>     > $(SHELL)
> $(top_srcdir)/tools/move-if-change SVN-REVISION-tmp
> SVN-REVISION ; \
> 
> That change needs another important change in
> src/main/version.c
> where the string "unknown" has been explicitly looked for.
> 
> I have now committed a patch to both ---
> using '-99' : something clearly "artificial", rather than
> '0'
> which looks too innocuous.

Thanks.

Genuine revision number starts from 1, so 0 does the minimal job of indicating it is not genuine. I can't remember what was the precise problem/symptom, possibly R showing a very ugly error message when it starts, trying to display some basic version info.

I have 7 such "continually locally applied modifications" at the moment - the oldest two dated back 14 months ago. The other 6 are something which are temporarily useful, or at least harmless, but not obviously correct way (or "one of the obviously correct alternatives") of doing things.

I certainly find that being able to carry "continually locally applied modifications", somewhat indefinitely and privately, from 40 days old to 14 months old, while tracking and incorporating upstream changes, and continue to make and track local changes, a useful feature of distributed version control systems in general, versus centralized version control systems. The 7th mod would have been either automatically dropped (if the up-stream applies the exact same change, which is 40 days later), or *offered* to be dropped/modified in this case when upstream applies a different change to the same code area. 

BTW, the current version of the recommended library Matrix has not been able to build since early September. (over 3 months ago). I assume that it will be fixed eventually, or before R 16, in the next few months.