HTML under RCS: commenting seems wrong

[Stephen J. Fromm]

I'm using RCS version 5.7 under Mandrake Linux 8.2.

How can I use RCS (ci, co, etc) with HTML files? When RCS sees
<!-- $Log$ -->
it doesn't seem to handle HTML commenting correctly. That is, it did this:

<!-- $Log: filename.html,v $
<!-- Revision 1.1 2003/06/23 14:23:46 stephen
<!-- Initial revision
<!-- -->

which is clearly not correct HTML commenting.

TIA,

sjfromm

[Kalle Olavi Niemitalo]

stephen.fromm@verizon.net (Stephen J. Fromm) writes:
<!-- $Log: filename.html,v $ <!-- Revision 1.1 2003/06/23 14:23:46 stephen <!-- Initial revision <!-- -->

RCS automatically duplicates whatever string precedes $Log$ on
the line. So if you put the $Log$ at the beginning of a line,
RCS will not use any prefix on the lines it inserts.

Initial input:

<!--
$Log$-->

Output from co:

<!--
$Log: filename.html,v $
Revision 1.1 2003/06/23 17:10:29 kalle
Initial revision
-->

Of course, you can indent the $Log$ if you prefer.

However, if you type "--" in a revision comment, that will still
confuse the HTML.

You could also explicitly set the comment prefix with "rcs
-cPREFIX", but RCS 5.7 seems to ignore that setting.

[Stephen J. Fromm]

kaz@ashi.footprints.net (Kaz Kylheku) wrote in message news:<cf333042.0306231349.666ca370@posting.google.com>... stephen.fromm@verizon.net (Stephen J. Fromm) wrote in message news:<b4cc5e7c.0306230625.380ddc0b@posting.google.com>... I'm using RCS version 5.7 under Mandrake Linux 8.2. How can I use RCS (ci, co, etc) with HTML files? When RCS sees <!-- $Log$ --> it doesn't seem to handle HTML commenting correctly. Don't use $Log$. It's an idiotic misfeature that should ideally be removed from RCS, and all software based on it. The concept is broken, and the design is broken.

Is this a common view?

The reason I like it is I want to be able to know the date of each version.
Expanding revision history into the body of the file creates an undesirable feedback loop through the system which leads to merge conflicts. This is why the concept is flawed. Failure to respect the commenting syntax of various languages causes syntax errors; code breaks on checkout, etc. This is why the implementation is flawed.

Well, it *seems* to work OK for C++ and HTML code.

Thanks,

sjfromm

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Stephen:

Stephen J. Fromm escribió en comp.software.config-mgmt:
kaz@ashi.footprints.net (Kaz Kylheku) wrote in message news:<cf333042.0306231349.666ca370@posting.google.com>... stephen.fromm@verizon.net (Stephen J. Fromm) wrote in message news:<b4cc5e7c.0306230625.380ddc0b@posting.google.com>... I'm using RCS version 5.7 under Mandrake Linux 8.2. How can I use RCS (ci, co, etc) with HTML files? When RCS sees <!-- $Log$ --> it doesn't seem to handle HTML commenting correctly. Don't use $Log$. It's an idiotic misfeature that should ideally be removed from RCS, and all software based on it. The concept is broken, and the design is broken. Is this a common view?

Yes, it is.
The reason I like it is I want to be able to know the date of each version.

Then you either are a developer with access to the repo or you are not, so
it migth interest to you knowing the date of the last release. For this
you can use the $Id$ tag.
Failure to respect the commenting syntax of various languages causes syntax errors; code breaks on checkout, etc. This is why the implementation is flawed. Well, it *seems* to work OK for C++ and HTML code.

Well, it seems, but what Kaz told is still true.
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[Tim Breitkreutz]

Here's why I like to use the RCS/CVS $Log$ feature:

1. If I'm reviewing work, and I use 'diff' on a revision and its
predecessor, you can immediately tell if someone accidentally created
a merge error by ignoring a previous version. I.e., the log file will
tell you if the new file was created from an incorrect version.

2. You can put an identifier for a "change unit", task, job, or
however you unitize your work into the log file. If this is done
automatically by a script or wrapper you have around RCS/CVS, then you
can immediately tell, from within the file, what the last few changes
this file was involved in, who did them, when, and a quick description
of what the change was. This is a *HUGE* time saving device when you
are working in a team with collective ownership of code. It even
works with hard-copy or when your network is down or your repository
server is unavailable.

3. It gives you visceral feedback on where your integration
bottlenecks are. Files that accumulate large $Log$s are immediate
candidates for refactoring. With enough imagination you should be able
to break up the files that are involved in too many changes.

My 2c.

[Jorgen Grahn]

On 25 Jun 2003 12:18:45 -0700, Tim Breitkreutz <pnorf@yahoo.com> wrote: Here's why I like to use the RCS/CVS $Log$ feature:

(Good points, trying to dispute them below...)
2. You can put an identifier for a "change unit", task, job, or however you unitize your work into the log file. If this is done automatically by a script or wrapper you have around RCS/CVS, then you can immediately tell, from within the file, what the last few changes this file was involved in, who did them, when, and a quick description of what the change was. This is a *HUGE* time saving device when you
....

When I stopped doing dollar-log it didn't take long, I think, for me to get
used to keeping a shell handy where I can do a quick 'cvs log' whenever I
need to. And I do use the log a lot when I work on something.

And besides, if you can live with the history not being *in* the file, a
whole bunch of other "situation awareness" tools become available. Some of
them (cvs2cl, for example) aren't limited to working on single files.
3. It gives you visceral feedback on where your integration bottlenecks are. Files that accumulate large $Log$s are immediate

On the other hand, large $Log$s <==> many revisions <==> high $Id$ numbers.

/Jorgen

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[Chris Pruett]

My personal opinion of $Log$ is that the pain far outweighs the gain. I
like it just a little more than the technique of keeping old changes
around in nearby, commented-out lines... 8^)

You have a point about detecting someone's mess-up of backing out a
revision. However, I only see this happen when someone copies an old
version, with edits, from one sandbox to another, instead of using the
tool to update/merge. If they do updates/merges it doesn't seem to
happen very often. $Log$ causes so many other problems when merging
branches (zillions of bogus conflicts and mods that must be reviewed)
it just isn't worth it.

I generally track "change units" in branches with the ticket ID in the
tag name and just do a quick cvs log or have tkcvs running to figure
out the history of a file. Especially with tkcvs, one can quickly diff
the various versions instead of relying on the developers' description
of what they did.

Actually, I do get a visceral feeling when I have to page past 1000
lines of $Log$ crap to get to the beginning of a module. This is
usually just before I delete the $Log$ block. Hot files make
themselves known in lots of ways, even without $Log$. When the version
number is three digits or when you find yourself merging and resolving
conflicts on it every other day, it's hot.

CP

In article <4c812878.0306251118.49724c92@posting.google.com>, Tim
Breitkreutz <pnorf@yahoo.com> wrote:
Here's why I like to use the RCS/CVS $Log$ feature: 1. If I'm reviewing work, and I use 'diff' on a revision and its predecessor, you can immediately tell if someone accidentally created a merge error by ignoring a previous version. I.e., the log file will tell you if the new file was created from an incorrect version. 2. You can put an identifier for a "change unit", task, job, or however you unitize your work into the log file. If this is done automatically by a script or wrapper you have around RCS/CVS, then you can immediately tell, from within the file, what the last few changes this file was involved in, who did them, when, and a quick description of what the change was. This is a *HUGE* time saving device when you are working in a team with collective ownership of code. It even works with hard-copy or when your network is down or your repository server is unavailable. 3. It gives you visceral feedback on where your integration bottlenecks are. Files that accumulate large $Log$s are immediate candidates for refactoring. With enough imagination you should be able to break up the files that are involved in too many changes. My 2c.

[Stephen J. Fromm]

Jesús M. NAVARRO <jesus_navarro@undominio.net> wrote in message news:<velss-f1v.ln1@mithrandir.intranet>... Hi, Stephen: Stephen J. Fromm escribió en comp.software.config-mgmt: [...] OK, so if I want to change it, can I just go into the RCS file (e.g. "source.cc,v") and change "$Log$" back to "$Id$"? No. That's uneeded. Since $Log$ problem only arises on "future" checkins (you wouldn't been asking about it if you had to affront its caveats), just send and e-mail to your development team

(smile) I *am* the development team. I'm working entirely on my own.
The reason I started using RCS is that I had been versioning my code
to avoid the "oh, crap, I need to get back to a working version
because I've *really* broken things now" problem, and it was a real
pain in the *** to do things like
$ cp source.cc OLD/source.cc.1.18
all the time.

And I learned it on the cheap: just read a few pages out of _Unix
Power Tools_, plus skimming a few of the relevant man pages on my
Linux box (Mandrake 8.2).
so when anybody is about to change a file with a $Log (whatever)$ they should change with an $Id$ tag and, ideally, reserve a checkin just for this change (that is: look if there're $Log (...)$ tags; change them with $Id$ if so, then commit, then go with their "real" changes). There's no need to change upfront any file, but do so prior to any further modification (indeed, if you don't branch, only drawback with $Log$ is it tends to go in the middle, but nothing worse).

I assume you mean that "no harm will occur by editing the actual RCS
file and changing $Log$ to $Id$, but there's no need to do so until
before you check out again."

I stress the business about whether harm will occur because in
principle, if you really screw up the RCS file itself (e.g.
source.cc,v), you could really ruin everything.

Thanks for all the helpful replies and information.

Cheers,

S

[Chuck Karish]

Stephen J. Fromm wrote:
OK, so if I want to change it, can I just go into the RCS file (e.g. "source.cc,v") and change "$Log$" back to "$Id$"?

Doesn't the RCS file have a checksum that will be incorrect
after you do that? You may have to "repair" the files
afterwards.

The bigger question is why would you want to do that? If it's
too much trouble to check out the files, edit them, and check
them back in, your SCM tool is inadequate.

[Kalle Olavi Niemitalo]

Chuck Karish <karish@well.com> writes:
Doesn't the RCS file have a checksum that will be incorrect after you do that?

No, it doesn't.

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Stephen:

Stephen J. Fromm escribió en comp.software.config-mgmt:
Jesús M. NAVARRO <jesus_navarro@undominio.net> wrote in message news:<velss-f1v.ln1@mithrandir.intranet>... Hi, Stephen: Stephen J. Fromm escribió en comp.software.config-mgmt: [...] OK, so if I want to change it, can I just go into the RCS file (e.g. "source.cc,v") and change "$Log$" back to "$Id$"? No. That's uneeded. Since $Log$ problem only arises on "future" checkins (you wouldn't been asking about it if you had to affront its caveats), just send and e-mail to your development team (smile) I *am* the development team. I'm working entirely on my own. The reason I started using RCS is that I had been versioning my code to avoid the "oh, crap, I need to get back to a working version because I've *really* broken things now" problem, and it was a real pain in the *** to do things like $ cp source.cc OLD/source.cc.1.18 all the time.

Now, it's even better! Being you yourself the development "team", you can
rest sure that you will follow the policies, once you understand and accept
them ;^D

So, I'd heavily suggest my previous policy: don't change anything. Just
reserve an exclusive commit for the change from $Log$ to $Id$ prior to any
change on a given file. It will be just few seconds "wasted" on those
files you are about to edit.
I assume you mean that "no harm will occur by editing the actual RCS file and changing $Log$ to $Id$, but there's no need to do so until before you check out again."

Yes I do.
I stress the business about whether harm will occur because in principle, if you really screw up the RCS file itself (e.g. source.cc,v), you could really ruin everything.

Then that's a deal! Don't touch the *,v files but when in heavy need, and
don't touch the files more than estrictly needed. From those two "common
sense" policies, you end up with my suggestion.
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[Greg A. Woods]

pnorf@yahoo.com (Tim Breitkreutz) writes:
Here's why I like to use the RCS/CVS $Log$ feature: 1. If I'm reviewing work, and I use 'diff' on a revision and its predecessor, you can immediately tell if someone accidentally created a merge error by ignoring a previous version. I.e., the log file will tell you if the new file was created from an incorrect version.

That's not going to work (well / at all) with branches. ;-)

--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>