0

I have some old code in CVS format (RCS format). I would like to avoid checking in a new revision only to fix the indentation, and not syntax. Often the original developer no longer has an account (they have left the company). If I were to fix that indentation, then that change is marked with my user account in cvs annotate output, which is undesirable. Since only indentation is changed, functionality is not changed. The net result is that, when the file is checked out again, its indentation is corrected, and a cvs annotate shows that line of the last "real" change and its associated author.

So, is this even possible with directly editing of the ,v RCS file (on a copy of the file on a locked down CVSROOT, for instance), or are there checksums that check for such editing (RCS format alludes to a "integrity" field but it is not clear if it is the thing that would invalidate this type of change)? Notice this is CVS-specific; other source code control systems such as Git have built-in mechanisms. (Migrating to those other systems is being considered but that is off-topic here).

https://stackoverflow.com/a/46713192/257924 seems to indicate there are tools readily available for parsing the underlying RCS format (,v files), so might be used for the basis of this in case it is actually true that there is some type of checksum in the file. But if I could just do the edits directly, that would be better.

torek
  • 448,244
  • 59
  • 642
  • 775
bgoodr
  • 2,744
  • 1
  • 30
  • 51
  • 1
    And if modifying the indentation were to have semantic side-effects you would presumably like the ability to roll-back this change, right? Which is why an edit is an edit. Not sure how git is relevant here; there is no amend another developers previous commit; now you could amend your own - but these original developers are long gone, so what does that matter? – Elliott Frisch Mar 20 '18 at 22:48
  • I'm going to remove the [tag:git] tag since Git is irrelevant here. – torek Mar 21 '18 at 00:05
  • Agreed. Git is irrelevant here. I should have not mentioned it. – bgoodr Mar 21 '18 at 04:20

2 Answers2

2

I would avoid rewriting the raw ,v file if you possibly can. Lots of things can go wrong in there, and the pool of people who can help dwindles each passing day.

I would suggest "lying" to RCS instead. Something like this:

$ co -l file.ext
$ prettyformat file.ext
$ lastauthor=$(rlog file.ext | awk '$1=="date:"{print $5;exit}')
$ ci -u -w"${lastauthor%;}" -m'formatting updates' file.ext

I don't know what your prettyformat command might be, but you can swap it in.

The basic idea here is that we WILL do an update to each file, but we'll "fake" the author name with -w. This is fine, it's just a text string in the ,v file, there's no magic associated with it.

If you're also concerned about dates, you could also fake them with the -d option:

$ lastmod=$(rlog file.ext | awk '$1=="date:"{print $2,$3;exit}')
$ co -l file.ext
$ prettyformat file.ext
$ lastauthor=$(rlog file.ext | awk '$1=="date:"{print $5;exit}')
$ ci -u -w"${lastauthor%;}" -d"${lastmod%;}" -m'formatting updates' file.ext

This way, if you choose to migrate things to something other than CVS in the future, the age of each file will be recorded correctly irrespective of the formatting changes.

ghoti
  • 45,319
  • 8
  • 65
  • 104
  • This seems like the most reasonable answer. I presume that the spoofed dates would not be monotonically increasing along with the revision numbers, which might be confusing. Or it just might be good enough, I don't know. However, this would have the distinct advantage of not having to ask permission in order to fix the indentation from the CVS administrator. – bgoodr Mar 21 '18 at 04:38
1

It's certainly possible in theory to rewrite an RCS revision file in place. It's quite tricky to achieve in practice, though. As the answer you linked notes, the content of an RCS ,v file is (are?):

  • the latest version in the trunk
  • with reverse deltas to produce each earlier trunk version
  • but with forward deltas to produce each branch version

What this means is that to replace a particular version somewhere, you must:

  1. Locate its position in the trunk or branch stream.
  2. If it is in the trunk, rewrite the previous trunk delta while replacing this specific trunk version, which may mean rewriting this delta or rewriting the intact final version in place;
  3. otherwise (it's a branch version), rewrite the subsequent delta while rewriting this version's predecessor's delta that leads to this version.

This process is likely to be pretty error-prone.

It's much simpler to just forge the user name. Produce an updated version of the file and commit it as the user you intend to get the credit/blame. If you control the system, you control whether some credentials are accepted. If not, you can't rewrite the ,v file anyway.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Very helpful. Even if I could rewrite the file directly, I couldn't sell this approach to the administrators I would have to go through in order to get the file replaced in the CVS server. – bgoodr Mar 21 '18 at 04:33