RCS keyword removal

RCS keyword removal

[Miles Bader]

I've committed a patch removing most uses of RCS keywords in emacs.

The ones I _didn't_ remove were in vc-*.el, and allout.el (this one I'm not
sure about; I just got a funny feeling about it).

-Miles
-- 
I'd rather be consing.

Re: RCS keyword removal

[Andre Spiegel]

On Sat, 2004-04-10 at 08:00, Miles Bader wrote:

> The ones I _didn't_ remove were in vc-*.el

Could you tell me what specific operations they cause you trouble with? 
(Others who are having trouble with version headers, please also
respond.)

There ought to be a way to enhance these operations so that they ignore
changes in version headers.

Re: RCS keyword removal

[Miles Bader]

On Sun, Apr 11, 2004 at 05:18:30PM +0200, Andre Spiegel wrote:
> On Sat, 2004-04-10 at 08:00, Miles Bader wrote:
> 
> > The ones I _didn't_ remove were in vc-*.el
> 
> Could you tell me what specific operations they cause you trouble with? 
> (Others who are having trouble with version headers, please also
> respond.)

With merging between different branches outside of CVS.  A merge is done, and
then the merged branches reconciled with CVS -- which changes the keywords,
and causes more spurious changes, which then end up becoming part of the long
term branch state.  These are then are persistant sources of merge conflicts
in future merges.

Ideally I could globally use the CVS -kb option on checkout/update to prevent
all keyword expansion, but the CVS docs are very unclear on the actual effect
of that, e.g what would the actual value of existing embedded keywords (in
existing code, or new code committed by people who _didn't_ globally force
-kb, i.e., most people)?

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: RCS keyword removal

[Andreas Schwab]

Miles Bader <miles@gnu.org> writes:

> Ideally I could globally use the CVS -kb option on checkout/update to prevent
> all keyword expansion, but the CVS docs are very unclear on the actual effect
> of that, e.g what would the actual value of existing embedded keywords (in
> existing code, or new code committed by people who _didn't_ globally force
> -kb, i.e., most people)?

We could make -ko the default via cvs admin.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RCS keyword removal

[Andre Spiegel]

Miles wrote:

> Ideally I could globally use the CVS -kb option on checkout/update to prevent
> all keyword expansion, but the CVS docs are very unclear on the actual effect
> of that, e.g what would the actual value of existing embedded keywords (in
> existing code, or new code committed by people who _didn't_ globally force
> -kb, i.e., most people)?

Keywords are only expanded in the checked-out versions of files.  The
expanded form is never stored in the RCS master files.  So, if somebody
switches off keyword expansion locally for himself (in a single command,
or permanently for an entire working directory), that doesn't affect
anybody else using the repository.

Switching off keyword expansion by default in the repository, as Andreas
suggested, would defeat the purpose of those keywords altogether,
though.  The point is that in released versions of the files, the
keywords ought to be expanded, otherwise they are useless, and I could
just do as RMS suggested and stamp the files myself when I send them
out.  I doesn't really address the problem keywords are needed for, but
I explained that already.

When merges are done within CVS, keywords shouldn't be causing any
trouble, because files are merged with keywords unexpanded, or at least
there's an option to say it should be that way.  However, when you use
the files from CVS in another version control system (Arch, in your
case), the issue becomes fuzzy.  A general approach might be to switch
off keyword expansion for anything that is checked in to Arch. 
Alternatively, a feature to tell Arch to ignore certain kinds of
differences could be implemented.

Re: RCS keyword removal

[Miles Bader]

Andre Spiegel <spiegel@gnu.org> writes:
> A general approach might be to switch off keyword expansion for
> anything that is checked in to Arch.

I'd like to do this, but have been nervous to because of my uncertainity
about CVS's behavior.  If people think it's safe to use `-kb' globally
I'll do that (from from my reading of the docs a global `-ko' is
dangerous though, as it overrides a file-specific -kb setting, and so
could conceivably cause problems with binary files).

If I'm interpreting the docs correctly, BTW, switching to `-kb' will
leave expanded keywords in currently checked-out files unchanged (that
is, if CVS stores keywords unexpanded in the repository, adding `-kb'
_won't_ suddently cause keywords in checked out files to revert to their
unexpanded forms), which might be slightly confusing for anyone relying
on RCS keywords in bug reports.

> Alternatively, a feature to tell Arch to ignore certain kinds of
> differences could be implemented.

But I'm not going to do that.

Thanks,

-Miles
-- 
97% of everything is grunge

Re: RCS keyword removal

[Andre Spiegel]

On Mon, 2004-04-12 at 03:48, Miles Bader wrote:

> I'd like to do this, but have been nervous to because of my uncertainity
> about CVS's behavior.  If people think it's safe to use `-kb' globally
> I'll do that

I'm not sure I understand the scope you are talking about.  If you mean
to switch off keyword expansion in the Emacs CVS repository as a whole
(so that I would be pretty much the only one who enables it locally),
then we might as well get rid of those keywords in vc-*.el altogether,
because it's really no point if only I keep them.

It was my understanding that these changes would only apply to the
version of Emacs that is managed in parallel using Arch.  My impression
was further that the Arch stuff is more of an experimental setup, and
not the main place of any development.  You also said that Arch has
better features to identify the version of the entire system, than CVS
with its keywords which apply only to single files.

Based on this, I would argue that the RCS keywords ought to be enabled
in the CVS repository (and thus be enabled in every developer's work
area by default, and the released versions of Emacs), until perhaps one
day Arch is used to maintain the Emacs sources completely (and releases
are made from the Arch tree).

> If I'm interpreting the docs correctly, BTW, switching to `-kb' will
> leave expanded keywords in currently checked-out files unchanged (that
> is, if CVS stores keywords unexpanded in the repository, adding `-kb'
> _won't_ suddently cause keywords in checked out files to revert to their
> unexpanded forms), which might be slightly confusing for anyone relying
> on RCS keywords in bug reports.

I don't quite see the point here.  Why don't you just check out your
work area anew, and all your keywords will be unexpanded?  All of this
assumes that we are only talking about disabling the keywords locally
(i.e. using "cvs update -kb file", rather than "cvs admin -kb file").

Re: RCS keyword removal

[Miles Bader]

Andre Spiegel <spiegel@gnu.org> writes:
> > I'd like to do this, but have been nervous to because of my uncertainity
> > about CVS's behavior.  If people think it's safe to use `-kb' globally
> > I'll do that
> 
> I'm not sure I understand the scope you are talking about.  If you mean
> to switch off keyword expansion in the Emacs CVS repository as a whole
> (so that I would be pretty much the only one who enables it locally),

No, I meant adding them to the `cvs update' command I use to update my
arch branches -- by global I was just referring to the whole emacs tree
(rather than e.g. a single file).

> It was my understanding that these changes would only apply to the
> version of Emacs that is managed in parallel using Arch.

Yes (or at least, that's all I meant).

> Based on this, I would argue that the RCS keywords ought to be enabled
> in the CVS repository (and thus be enabled in every developer's work
> area by default,

Yes, except, of course, developers who use arch instead of CVS.

> and the released versions of Emacs

That's an issue for others to decide (they are probably less useful in
a released emacs than for CVS users).

-Miles
-- 
Fast, small, soon; pick any 2.

Re: RCS keyword removal

[Miles Bader]

Andre Spiegel <spiegel@gnu.org> writes:
> I don't quite see the point here.  Why don't you just check out your
> work area anew, and all your keywords will be unexpanded?  All of this
> assumes that we are only talking about disabling the keywords locally
> (i.e. using "cvs update -kb file", rather than "cvs admin -kb file").

Ok, I tried this ... and it didn't work.  I did:

   CVSROOT=... cvs co -kb -d test-emacs emacs

and files containing RCS keywords within `test-emacs' still had expanded
keyword values -- though the expansions were different than the `normal'
expanded values (they were slightly out of date, and seemed to contain
info for the revision just prior to the last one).

I'm still confused as to what exactly CVS is doing with this stuff, but
one model that might be consistent with the behavior I observe is that
CVS (1) expands keywords only on checkout/update, and (2) stores the
expanded keywords in the repository when you commit (i.e., commit
doesn't modify what's committed), (3) commit _does_ update the working
copy of the file after the commit (i.e., there's always an implicit
update after commit).

If I'm correct about what's going on, then it seems:

 (1) If I use `cvs update -kb', the arch tree will still contain the
     expanded keywords, but the values will be slightly bogus.

 (2) The only way I can get consistent values between my different CVS
     branches is to actually check in the values I want into the other
     (CVS) branches (which might annoy CVS users, as the info then will
     be completely wrong -- e.g., the revision number in $Revision$ will
     be for a completely different branch).

 (3) Subsequent checkins by other CVS users (who aren't presumably using
     update -kb) will still change the keyword expansions I see.  This
     won't be as bad as the current situation though, as at least my own
     commits won't cause changes in my working copy.

I.e. what a mess...

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: RCS keyword removal

[Andre Spiegel]

On Tue, 2004-04-13 at 11:10, Miles Bader wrote:

> Ok, I tried this ... and it didn't work.  I did:
> 
>    CVSROOT=... cvs co -kb -d test-emacs emacs
> 
> and files containing RCS keywords within `test-emacs' still had expanded
> keyword values -- though the expansions were different than the `normal'
> expanded values (they were slightly out of date, and seemed to contain
> info for the revision just prior to the last one).

I think you need to use "cvs co -kk ...".  That explicitly resets the
keywords to their unexpanded form.  It seems that -kb reverts to
whatever form the keyword happens to have in the RCS master file, which
is bogus because it is rewritten upon checkout anyway.  So, -kk ought to
be the right option.

(-kb makes sense for binary files, because if a file happens to contain
something that looks like an expanded RCS keyword, you wouldn't want
that to be reset.)

Re: RCS keyword removal

[Miles Bader]

On Tue, Apr 13, 2004 at 11:29:53AM +0200, Andre Spiegel wrote:
> I think you need to use "cvs co -kk ...".  That explicitly resets the
> keywords to their unexpanded form.  It seems that -kb reverts to
> whatever form the keyword happens to have in the RCS master file, which
> is bogus because it is rewritten upon checkout anyway.  So, -kk ought to
> be the right option.

Since co/update -k options override all file-specific settings (and thus
might screw up binary files if used globally) I guess what I should do is
checkout only those few files in emacs that still use RCS keywords using -kk
and rely on the fact that it's a sticky option.  [It's a shame because it
would seem to be a much more robust solution to somehow have the CVS/arch
gateway script do it.]

Thanks,

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: RCS keyword removal

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Andre Spiegel <spiegel@gnu.org> writes:
> > A general approach might be to switch off keyword expansion for
> > anything that is checked in to Arch.
> 
> I'd like to do this, but have been nervous to because of my uncertainity
> about CVS's behavior.  If people think it's safe to use `-kb' globally

IIRC, -kb also implies that line-end translation is inhibited on e.g. windoze.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: RCS keyword removal

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > Andre Spiegel <spiegel@gnu.org> writes:
> > > A general approach might be to switch off keyword expansion for
> > > anything that is checked in to Arch.
> > 
> > I'd like to do this, but have been nervous to because of my uncertainity
> > about CVS's behavior.  If people think it's safe to use `-kb' globally
> 
> IIRC, -kb also implies that line-end translation is inhibited on e.g. windoze.

Right, but that's not a problem as I'm not using windows (remember, I just
want to use -kb for _my_ checkout for arch synchronization), and as the -kb
option to cvs update apparently overrides file-specific settings, it seems
necessary to use an option which preserves file-specific -kb settings on
binary files.

-Miles
-- 
Run away!  Run away!