Thanks Gabor, Duncan, and Dirk,
for your replies.
Gabor Grothendieck wrote:
> We need to make sure we understand the implications
> for packages developed under the other major version
> control systems like git, bzr and hg.
Ok for this --- of course it would even be "greater" to have
a universal replacement scheme for general version control
systems in R for DESCRIPTION files, but actually for the moment
I would already be content with some R tools (possibly a collection
of them) for each version control system individually.
> On 31 March 2009 at 12:58, Duncan Murdoch wrote:
> | On 3/31/2009 10:41 AM, Peter Ruckdeschel wrote:
> | > Could we have one (or maybe more) standardized optional tag(s)
> | > for package DESCRIPTION files to cover svn revision info?
> | > This would be very useful for bug reporting...
>
> Indeed. I am doing something similar with local packages at work.
>
> | > I know that any developer is already free to append corresponding lines
> | > to DESCRIPTION files to do something of this sort --- e.g. lines like
> | >
> | > LastChangedDate: {$LastChangedDate: 2009-03-31 $}
> | > LastChangedRevision: {$LastChangedRevision: 447 $}
> |
> | That will give you the last change to the DESCRIPTION file, not the last
> | change to the package, so it could be misleading. Last time I looked,
> | there wasn't a way in svn to auto update a file that wasn't involved in
> | a changeset.
Ouch. I stand corrected; and I have to say: this even is an FAQ
in the SVN documentation... So using svn properties will not work indeed.
Still, my wish for a better integration of version control
information into R persists...
So if I understand correctly, under linux / cygwin (Mac I don't know)
you would use some scripting to read out the output of svnversion;
let me add that under Windows + Tortoise SVN you would have
SubWCRev (http://tortoisesvn.tigris.org/faq.html#subwcrev) to help you.
> (You could put something into your build script to call
> | svnversion, but I don't know anything simpler.)
>
> Yes, I have been using configure for that (which can be really any type of
> executable script rather than something from autoconf). One can then either
> update a placeholder in DESCRIPTION.in to substitute the revision number
> and/or create a package-local function reporting svn revision, build time,
> etc.
>
> It may make sense to think about a more general scheme. A common problem is
> of course once again portability and the set of required tools.
If we are talking about R functions for reporting version control
information --- what about the following scheme:
-have some version control system individual functions (one for svn, one
for git and so on)
-have some S4 control class for each of these version control systems
-have an S4 generic VCinfo() which dispatches according to an argument
VCsystem of this control class
This would give some additional flexibility to integrate infra-structure
for new version control systems ---even by other programmers--- without
interfering with the generic.
For the scripting approach --- what about some extra options for
R CMD build
for instance --withSVN or --withTortoiseSVN ?
Thanks again for your comments --- and apologies for my wrong idea
using svn properties.
Best, Peter
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
