Re: The hated $Log$ keyword

[Eric Siegerman]

On Sun, Jul 08, 2001 at 10:39:52PM -0400, Greg A. Woods wrote:
> The "evil" thing abou RCS keyword design is that they contain their
> values when stored in the ,v file,

Mmm, yes.  If it stripped out the values at commit time, and just
stored the keywords, all these *#(! merge conflicts would go
away.


> and that they contain their markers
> when they appear in a "frozen" file.

Why is this a problem?  I very much prefer it.  Suppose, using
SCCS or raw RCS, I accidentally edit a file I haven't locked.
With RCS, once I've seen the "permission denied" message, I can:
  :!co -l foo
  :w!

The SCCS equivalent would inappropriately freeze all my keywords.

OK, that's a really dumb thing to do when collaborating with
others.  But then, I've rarely collaborated using raw RCS, and
never with SCCS; by the time I had coworkers who were willing to
consider version control at all, I'd discovered CVS :-)

> This was one of the several things that hindsight shows us SCCS did
> right in the first place, especially when you're using it as an
> underlying tool for delta management in something like CVS.

I don't see how one could even do CVS-style unreserved checkouts
layered on top of something which handled its keywords the way
SCCS does.  Should a checkout give you the values (in which case,
the magic-keyword-ness is lost on commit), or the keywords (in
which case, why bother with keywords in the first place since
they never get substituted)?

I'm trying to think of how one could get this to work.  You'd
have to do some kludge like:
  - check out with values only into the user's sandbox (actually,
    SCCS itself gives you no choice, if I recall, since the only
    way to get keywords only is "get -e", which also acquires a
    lock)

  - at commit time, do a merge between:
      1. a fresh checkout with values only
      2. another fresh checkout with keywords only
      3. the sandbox file
    i.e. diff (1) and (2) and apply the results to (3) as a patch

Shudder!  Every commit becomes a merge; it happens at commit
time, not update time, so the user can't inspect the results; a
conflict is guaranteed if the user so much as touches the
keyword-values or their immediate vicinity; two revision
checkouts per commit.  Have I listed all the problems yet?
Likely not...


> 
> >   - why do you put $Header$ in the "totally evil" class, not
> >     merely evil?
> 
> $Header contains information that has no business ever being seen in the
> file content, especially in CVS, though even in plain RCS use it is
> bogus.  If you move your repo all that info becomes wrong even though
> nothing else has to break.

Point taken.

> Well over a decade ago I argued for [...]
> a way to expand just the relative path-prefix within
> the repository

Now that you mention it, I seem to recall wishing for the same
thing (not quite a decade ago), but never got around to griping
about it.  Maybe I should have :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)