| Re: Version control for IDL software [message #46447 is a reply to message #46302] |
Sat, 19 November 2005 20:11   |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
"Richard G. French" <rfrench@wellesley.edu> writes:
> I'm working with several students on the development of a set of data
> analysis tools in IDL, and I'd like to use some sort of version control for
> the IDL software. The programs reside on an OSX server but are accessible
> from a variety of other Mac machines. I'm running IDL under Mac OSX.
>
> I'd appreciate hearing from UNIX folks about the relative merits of CVS and
> RCS, or other approaches, to keeping track of versions of procedures and
> functions that are called from other IDL routines, or if this is even
> possible within the CVS/RCS paradigm.
If you are talking about version control, then yes, I use CVS all the
time and it works great. I'm sure that any of the version control
systems that have been developed over the past few years would work
well too.
> If these tools don't do the job, I'd like advice on other ways to make sure
> that I have a record of the exact versions of program files called by a
> given large IDL program. I'm less worried about two users editing the same
> file at the same time, and more concerned with coming up with a sensible
> scheme whereby we can 'freeze' a given version of a routine and feel fairly
> confident that we know which version is used at any given time.
I would call this "configuration control." Here is what I do for a
reasonably large system.
For each of the important routines in the project, I have a line like
this:
idlx_cue_rcsid = '$Id: idlx_cue.pro,v 1.7 2001/07/21 17:41:12 craigm Exp $'
Of course, each time I change the module, CVS will automatically
update this line to the new version info, so this implants version
information into the procedure automatically.
Then step two is a simple cron job which runs every night that does
grep "_rcsid =" *.pro > idlx_rcsids.pro
This works fine if you are using your development version for real
work. Of course if you have a production-level "release" where the
modules are frozen, you can do this manually once and then freeze the
idlx_rcsids.pro file too.
The last step is to have a simple routine like this to print all the
relevant version information.
pro idlx_prversion
print, !version.release, !version.os, !version.arch, $
format='(" IDL Version: ",A0," ",A0," ",A0)'
cd, current=cwd
print, ' Current Directory: ', cwd
hostname = getenv('HOST')
if hostname(0) EQ '' then spawn, 'hostname', hostname
print, ' Current Host: ', hostname
@idlx_rcsids.pro
vars = routine_info('idlx_prversion', /variables)
for i = 0, n_elements(vars)-1 do begin
if strpos(vars(i),'_RCSID') GE 0 then $
dummy = execute('print, '+vars(i))
endfor
end
This could be done differently, by stuffing the rcsids into a
structure or something like that, but I was looking for the minimum
amount of effort that preserved the maximum version information. And
the most important thing is that it is all automatic so I never have
to touch anything for it to happen.
Hope that helps. Good luck!
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@REMOVEcow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
