Hi Spencer, Each commit increments the svn revision number regardless of the build status. md5sums on pkg may not change for commits (only) to www and branches.
Yes, the DESCRIPTION file contains a field containing the package version number. The author edits that field and commits that change whenever they like. AFAIK Matthew "Spencer Graves" <spencer.gra...@structuremonitoring.com> wrote in message news:4c769939.9050...@structuremonitoring.com... Hi, Russ: As noted by Brian Peterson in a separate email, R-Forge has a "Revision" number in addition to the version number. For example, the 'fda' package is currently at version 2.2.3 with Rev.: 484 on R-Forge. Each SVN Commit increments the Rev. number [after a successful build, I think], but the version number only changes if that change includes a change in the revision number in the DESCRIPTION. I don't know for sure, but I assume that the "md5sums" probably changes with each Rev. If this is NOT correct, I hope someone who knows will clarify this. Best Wishes, Spencer ######################## I earlier moved a part of this thread to R-Devel, and got some replies there. At least one page on R-Forge says, "We are currently adapting the R-packages-plugin in order to work together with the new FusionForge infrastructure. Some services are thus not yet available." I don't know if R-Forge is accepting new volunteers, but it looks like they could use help. Unfortunately, I'm not in a position to volunteer. Best Wishes, Spencer Graves On 8/26/2010 8:28 AM, R P Herrold wrote: > On Thu, 26 Aug 2010, Gavin Simpson wrote: > >> On Thu, 2010-08-26 at 02:30 -0400, David Kane wrote: >>> How reliable is R-Forge? http://r-forge.r-project.org/ >>> >>> It is down now (for me). Reporting "R-Forge Could Not Connect to >>> Database: " > > late to chime in, so had tossed the first piece. As this relates to > 'reliability of R-Forge' in the sense of possible process issues, > rather than availability of the archive, I wanted to 'tag into' this > thread > > I 'mirror' r-forge, so I have not seen this ... > > One thing I note, mirroring r-forge, and processing 'diffs' netween > successive days, is that the md5sums of some packages regularly change > without version number bumps. From this morning's report in my email: > > Thu Aug 26 04:30:01 EDT 2010 > > --- /tmp/rforge-pre.txt 2010-08-26 04:30:33.000000000 -0400 > +++ /tmp/rforge-post.txt 2010-08-26 04:38:03.000000000 -0400 > @@ -8,18 +8,18 @@ > AquaEnv_1.0-1.tar.gz 615059a5369d1aba149e6142fedffdde > ArvoRe_0.1.6.tar.gz c955ae7c64c4270740172ad2219060ff > BB_2010.7-1.tar.gz 4f85093ab24fac5c0b91539ec6efb8b7 > -BCE_2.0.tar.gz 5a3fe3ecabbe2b2e278f6a48fc19d18d > -BIOMOD_1.1-5.tar.gz d2f74f21bc8858844f8d71627fd8e687 > +BCE_2.0.tar.gz 65a968c586e729a1c1ca34a37f5c293a > +BIOMOD_1.1-5.tar.gz 6929e5ad6a14709de7065286ec684942 > ... > -BTSPAS_2010.08.tar.gz 16b8f265846a512c329f0b52ba1924ab > +BTSPAS_2010.08.tar.gz 809a96b11f1094e95b217af113abd0ac > ... > -BayesR_0.1-1.tar.gz 72bd41c90845032eb9d15c4c6d086dec > +BayesFactorPCL_0.5.tar.gz 173ab741c399309314eff240a4c3cd6f > +BayesR_0.1-1.tar.gz 9560b511f1b955a60529599672d58fea > ... > -BiplotGUI_0.0-6.tar.gz 594b3a275cde018eaa74e1ef974dd522 > +BiplotGUI_0.0-6.tar.gz 857a484fdba6cb97be4e42e38bb6d0fd > ... > -IsoGene_1.0-18.tar.gz 679a5aecb7182474ed6a870fa52ca2e3 > +IsoGene_1.0-18.tar.gz f37572957b2a9846a8d738ec88ac8690 > > and so forth. I've not taken the trime to understand why seemingly > new versions are appearing without version bumps yet. > > Is anyone aware of explanations, other than a release process that > does not require unique versioning of differing content? [it seems > pretty basic to me that a 'receiver' of new content could do the > checks I do, and decline to push conflicting md5sums over an > identically named prior candidate in archive] > > -- Russ herrold > > ______________________________________________ > r-h...@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
