On Saturday, May 4, 2002, at 01:10 , Kevin Old wrote:
[..]
> I use ci/co and like the versioning stuff on it....should I just stick
> with
> that? I'd love to hear other's experiences and opinions. Also, any
> examples of scripts you've done in different stages.
[..]
I'm frightfully depressed that Chris Ball took most of the really
good bits and has left me with little more than this piece.
I presume that you know how to use the $Id$ and the rest of
that already - hence that you have opted to make template files
for your perl code that has all of that already embedded, along
with the obligatory copyright and reference to the relevant
legal disclaimer boiler plate - basically skag what you
did in your 'c' code - change the 'comment bar style' carry
on smartly. { cf: 'man rcsintro' for those of you playing at home. }
You really should only change your source code control system
if:
a) the compensation package they offer is worth it.
b) it resolves other deep seated childhood issues hence
cutting down on your medical expenses { getting your
CPA to cover your bar bill as a medical expense under
the current tax rules not withstanding. Seek professional
help on this point.}
c) it gets you a cutting edge over the other coders in your
organization in the 'source code control games'.
One trick you will notice from the 'things that came free with
the h2xs stuff' is the idea of a MANIFEST and a Changelog -
both of which you should source code control - and using the
Changelog to keep track of which ci's were 'safety throws'
to protect against majik, and which ones were the real incrementing
of a rev value as outlined so elegantly by Chris.
{ yes do the perldoc h2xs } - since while at this point it may
not be quite as clear why you want to figure out why you are
generating the
FOO::BAR
suite at this point - by the time you have cobbled together
enough stuff to figure out which of it was what you really
wanted to do - you will have found that having the prototype
of the PM already to play with was a good idea.... since now you
have all of that down in the 'lib' subdirectory, and you
executables in the 'bin' directory and you are pleasantly
on a first name basis with the whole suite of Make Utils,
since of course your 't' sub directory has all the test
code anyone would ever want to validate as much as can
be done, and hence the
make distribution
will gin up the right type of tarball that allows for the
consumer to unwrap it and run -
perl *.PL
make
make test
make install
and MAJIKCALLY your code is where it should be, and the
requisite modules just landed in the site_perl, the
man pages as required and the pod is self explanatory
allowing further extensions to be created efficiently.
and all of your code - since you were using
Getopt::Long
of course knows that '-v' or --version will return
the relevant embedded $VERSION string - that of
course gets appended to the '-h' or --help or --usage
assertions - so that everyone is on the same page -
and of course the
perldoc <myCoolApp>
is likewise the quintessential helpful guide to the
user who will also be able to notice at the drop of
the hat that your Version string expanded and that
they are currently using the correct rev.
did I miss anything relevant in this with version
skew prevention tools?
ciao
drieux
---
Do NOT try this at home kids, these are PAID PROFESSIONAL
using the Latest in Saskatcheun Salmon Skin Safety Equipment....
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
