Despite it might help, learning/using git is not tackling this specific problem, I suggest code that does:
sed -e 's/^[\ \t]*//' -e 's/#.*//' R/* | awk '/function/{print $1}' | sort | uniq -d or https://gist.github.com/setempler/7fcf2a3a737ce1293e0623d2bb8e08ed (any comments welcome) If one knows coding R, it might be more productive developing a tiny tool for that, instead of learning a new (and complex) one (as git). Nevertheless, git is great! Best wishes, Sven --- web: www.templer.se twitter: @setempler > On 23 Jul 2016, at 16:17, Hadley Wickham <h.wick...@gmail.com> wrote: > > I think this sort of meta problem is best solved with svn/git because you > can easily see if the changes you think you made align with the changes you > actually made. Learning svn or git is a lot of work, but the payoff is > worth it. > > Hadley > > On Friday, July 22, 2016, ProfJCNash <profjcn...@gmail.com> wrote: > >> In trying to rationalize some files in a package I'm working on, I >> copied a function from one file to another, but forgot to change the >> name of one of them. It turns out the name of the file containing the >> "old" function was later in collation sequence than the one I was >> planning to be the "new" one. To debug some issues, I put some print() >> and cat() statements in the "new" file, but after building the package, >> they weren't there. Turns out the "old" function got installed, as might >> be expected if files processed in order. Debugging this took about 2 >> hours of slightly weird effort with 2 machines and 3 OS distributions >> before I realized the problem. It's fairly obvious that I should expect >> issues in this case, but not so clear how to detect the source of the >> problem. >> >> Question: Has anyone created a script to catch such duplicate functions >> from different files during build? I think a warning message that there >> are duplicate functions could save some time and effort. Maybe it's >> already there, but I saw no obvious message. In this case, I'm only >> working in R. >> >> I've found build.R in the R tarball, which is where I suspect such a >> check should go, and I'm willing to prepare a patch when I figure out >> how this should be done. However, it seems worth asking if anyone has >> needed to do this before. I've already done some searching, but the >> results seem to pick up quite different posts than I need. >> >> Cheers, JN >> >> ______________________________________________ >> R-package-devel@r-project.org <javascript:;> mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > > -- > http://hadley.nz > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel