RE: Patch for making CommitID configurable

[Jim.Hyslop]

Peter Backes wrote:
> Just think about what *is* the big advantage of CVS besides working 
> on RCS files instead of a strange ever-changing file format?
"ever-changing"? I think you're exaggerating here. When was the last time
the RCS file format changed?

What's the point in having the rcsfile(5) specification have the
"newphrases" spec, if you aren't going to use it?
(http://www.daemon-systems.org/man/rcsfile.5.html)

> I don't 
> see any.  If you do not need this core feature, there are much better 
> alternatives to pick from, like Subversion, and they provide much 
> more than just writing a commit ID without ever using it!
Incrementally adding a new feature is a lot less of a change, and a lot less
drastic, than switching to an entirely new system.

The way you're talking, it sounds as if you are saying that, once a program
is released, it should never change, and if you want new features you should
write a whole new, different program to add those features. Is that really
what you're proposing?

> Having said this, it is obvious that it should also be a question of 
> whether CommitID should be kept as a feature *at all*.
No, it is not obvious at all. It is only obvious if one is intent on keeping
the status quo.

> It is much 
> better to use the loginfo feature with the already present commitlog 
> and then pick the changeset from this one (and that is already 
> possible entirely without any change to cvs itself!) instead of 
> relying on writing some hard-to-retrieve info into rcs files.
For what definition of "better"? Better for _you_, perhaps, but not for the
dozens or hundreds of users (like me) who _want_ this feature.

Using commitinfo requires 
- each and every installation to make the same changes to their existing
commitinfo scripts; this requires hundreds of hours of wasted, duplicated
effort. Sure, you could make a generic commitinfo script available - but if
anyone already *has* a commitinfo script, then they won't be able to use the
canned one.

- tracking the commit ID in a separate database. Separating the commit
information (i.e. the ID and the log) is not a good idea.

> When does a commit ID make sense?  Only in a distributed environment, 
> where a revision must be identified uniquely independent of it's 
> number.
Huh? Not! The commit ID allows me to determine which files were committed in
a single operation. It has no bearing on distributed environments. I'm
looking at a file, and the log says "Fixed such-and-such a bug." I want to
know what other files were committed at the same time. Currently, I have to
rely on narrowing it down by timestamp, using a difficult-to-remember, not
very obvious technique for entering timestamps. Or, I could just type in the
commitID and there it is.

> How about tags?  Don't they also provide just the solution to the 
> problems commit ID was added for?
Assuming that each and every commit is tagged, perhaps. But that's not
necessarily the case, and it's certainly not a practise I would encourage.

> > Another alternative might be to provide a patch to the RCS 
> maintainer
> > to support any of the newphrase formats that CVS has introduced...
> 
> Please don't ...  RCS is stable, and the files it writes have been 
> the same for years
And your point would be... what, exactly? Does RCS not have any kind of a
test suite to check for problems?

> So please don't change rcs anymore except for bug fixes!  
So, let me get this straight. Just because *you* don't see any value in a
new feature, you want to prevent everyone else from using that feature?
(that was a rhetorical question, by the way - I'm sure that is not what you
intended).

Can you provide some objective reasons for not changing RCS? So far, all
you've given us is an impassioned plea for keeping the status quo, without
really giving any substantial reasons.

> CVS is to be built upon the things given by RCS, not the other way 
> around.
CVS *was* originally built on RCS. Why should it remain that way forever?

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. ( http://www.leitch.com )
Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )