Re: Including file version during checkout

[bollu]

>Hello,
Hello,

>I am using cvs for source control. In source file I want to auto include
>cvs version of file.

>for example: if foo.c has version 1.2 in cvs than is there any
>predefined
>variables that I can use in foo.c #define vesion $CVSVERSION$

You can use the keyword $Revision$ as explained in cederqvist (§12).
Though I've read unhappy comments about this feature in this list.

Cyrille

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | |
v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v v
v v v
On Thu, 19 Sep 2002, David Rosenstrauch wrote:

> We're running into this exact problem.  We just merged from a branch back

> onto the trunk this morning, but got a ton of merge conflicts - all of
them
> having to do with the $Log$ keyword.  None of the -k substitution options

> are fixing the problem (-ko, -kk) - and they're even causing more
problems,
> since they whack the -kb status that binary files have.
>
>
> Anyone know of any workarounds to this situation?

The workaround is to delete $Log$ from all your files, along with all
the crap it has ever generated. Then commit.

Treat any conflict within a $Log$-generated text area as irrelevant;
just blow away the whole section including the conflict.

The $Log$ keyword is next to useless, because all it does is reproduce
information that is already available in the repository.

Unless the commit messages are conscientiously written, they are
unlikely to be of value to anyone, and even if they are so written,
they won't be of use to anyone who has no access to the repository,
because they describe changes recorded in inaccessible past versions.
You need access to the old versions to fully comprehend what the messages
are talking about. Lastly, you want an integrated log of changes for
the project or module as a whole; so learn to maintain ChangeLog files.
A bunch of expanded $Log$'s scattered in a file tree is useless compared
to a well-maintained ChangeLog.

I've worked with people who insisted on $Log$ as a policy; it was
frustrating dealing with the merge problems. None of these people
understood or performed the merges.

If some goofball insists on $Log$, make him do all the merges
for a month. ;)