Keiron,
Here's how the RCS works.
$ rlog names
RCS file: names,v
Working file: names
head: 1.2
branch:
locks: strict
access list:
symbolic names:
Rel_1: 1.1.1.2
RC1: 1.2.1.3
Rel: 1.1.1
Dev: 1.2.1
Base: 1.1
keyword substitution: kv
total revisions: 7;
This page has the cvs keywords:
http://www.loria.fr/~molli/cvs/doc/cvs_12.html
None of them seem to be useable for the version of a product.
You still need to change something to make this update anyway.
On 2002.04.05 00:44 Peter B. West wrote:
Keiron,
I don't know the nuts and bolts of
Keiron,
As I suspected, $Name$ is the tag used to check out the file. In my
maint checkout, I have a sticky CVS/Tag specifying fop-0_20_2-maintain
(symbolic names cannot contain dot, because a revision is composed
of one or more numeric or symbolic fields separated by periods -
Arved,
Obviously, I share many of your attitudes to properties, but I differ in
one respect. I think of properties not as rich, but as impoverished.
To me, they are just associations of names with values. The richness
lies in their treatment in the process of layout, where all of those
Hi, Peter
I personally agree that the properties don't need the XML+XSLT approach.
Even if one leaves aside the aural properties there are over 250 properties,
and on close inspection the commonalities are limited. I believe the largest
group size of properties that are identical is 4. Many
Keiron,
I don't know the nuts and bolts of CVS, but I always assumed that tags
were somehow related to the RCS symbolic name, accessible via $Name$.
$Name$ has some peculiarities due to the fact that there is not a
unique name attached to the current version; I think it is set in the
output
On 2002.04.03 18:23 Peter B. West wrote:
There are a couple of other things which encourage the separation of
source and build.source trees. They involve the use of copy filtering
in ant. Version information is, I think, supplied by ant via the
build.xml file. This vile and disgusting
