Skip to content

small issue with over-zealous clean.

11 messages · Dirk Eddelbuettel, Martin Maechler, Hin-Tak Leung +2 more

Original
Hin-Tak Leung
# 
Noticed a problem for a while - tests/testit.Rd, tests/ver20.Rd are removed on "make clean" unintentionally.

This seems to come from a change in tests/Makefile.in, which adds the line:
   - at rm -f *.tar.gz *.Rd back in May 2012.

-----------
commit c4d70254e7b7f9d7ed17faecfb3097195d852ddc
Author: ripley <ripley at 00db46b3-68df-0310-9c12-caf00c1e9a41>
Date:   Sun May 27 09:04:41 2012 +0000

    fix some issues seen by examining no-segfaults.Rout
    
    git-svn-id: https://svn.r-project.org/R/trunk at 59451 00db46b3-68df-0310-9c12-caf00c1e9a41
----------

svn users probably don't notice files are unintentionally removed; git-svn does complain about version-controlled files being missing during rebase (i.e. re-applying local private patches to an updated upstream).

TIA.
Dirk Eddelbuettel
#
On 9 December 2012 at 18:17, Hin-Tak Leung wrote:
| Noticed a problem for a while - tests/testit.Rd, tests/ver20.Rd are removed on "make clean" unintentionally.
| 
| This seems to come from a change in tests/Makefile.in, which adds the line:
|    - at rm -f *.tar.gz *.Rd back in May 2012.
| 
| -----------
| commit c4d70254e7b7f9d7ed17faecfb3097195d852ddc
| Author: ripley <ripley at 00db46b3-68df-0310-9c12-caf00c1e9a41>
| Date:   Sun May 27 09:04:41 2012 +0000
| 
|     fix some issues seen by examining no-segfaults.Rout
|     
|     git-svn-id: https://svn.r-project.org/R/trunk at 59451 00db46b3-68df-0310-9c12-caf00c1e9a41
| ----------
| 
| svn users probably don't notice files are unintentionally removed; git-svn does complain about version-controlled files being missing during rebase (i.e. re-applying local private patches to an updated upstream).

svn marks missing files via a '!' (and unknown/unexpected files with a '?'):

edd at max:~/svn/r-devel/tests$ svn st
?       Makefile
!       ver20.Rd
?       Native/Makefile
?       Examples/utils-Ex.Rout.fail
?       Examples/Makefile
!       testit.Rd
?       Embedding/Makefile
edd at max:~/svn/r-devel/tests$ 

Do you REALLY think svn would not know about missing files?  There does not
seem to be a limit on the disdain for svn among git users. Fascinating.

Dirk
Hin-Tak Leung
#
--- On Sun, 9/12/12, Dirk Eddelbuettel <edd at debian.org> wrote:

            

      
      
      
    

        
Sorry about the over-sight on subversion - to be honest I have not been using subversion itself at all, since I am happier with git-svn (entirely my own opinion). That said, please do not distract the issue - a small bug was introduced back in May which you seem to corroborate.

Thanks for confirming the issue being also seen with subversion, nonetheless.

I know a few number of people who are happier with bzr, darcs, mercurial. That doesn't really say much about anything.

Hin-Tak

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        
[..... dropped
 ..... embarrassing / amusing distraction on svn/git ..... 
 ..... started by the OP, not by Dirk !
]

            

      
      
      
    

        
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/)

Martin

  
  


  


      

    

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

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

        

            

      
      
      
    

        
That comment is a bit childish, don't you think?

            

      
      
      
    

        
"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 ; \

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        

        
> --- 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.

Martin

  
  


  


      

    

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

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

        

            

      
      
      
    

        
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.

  
  


  


      

    

    
3 days later

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

      
--- On Sun, 9/12/12, Dirk Eddelbuettel <edd at debian.org> wrote:

        
<snipped>

            

      
      
      
    

        
FWIW, as one of the linux kernel maintainers, I don't apologize for being familiar with git. I did not decide git as the official tool for maintaining the linux kernel. Linus did.

There does not seem to be a limit on the disdain for the linux kernel among debian users.
Fascinating.

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 14.12.2012 04:15, Hin-Tak Leung wrote:

            

      
      
      
    

        
There *is* no limit on the disdain for people discussing off-topic 
svn/git/linux disdains on the *R*-devel list among R developers.

Uwe Ligges

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

      
--- On Fri, 14/12/12, Uwe Ligges <ligges at statistik.tu-dortmund.de> wrote:

        

            

      
      
      
    

        
That needs a "Fascinating" exclamation at the end to be genuine and authentic for the typical R developers/debian users.

  
  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Dec 14, 2012, at 1:48 PM, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:

        

            

      
      
      
    

        
That's enough of this off-topic subject matter. Take it off list if you wish to continue this dialog.

Any further posts to R-Devel in this vain will not be tolerated.

Marc Schwartz
R-Devel Co-Admin