RE: Patch for making CommitID configurable

[Peter Backes]

Hello,

On 26 Apr 2005 at 16:02, Jim.Hyslop wrote:

> 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? 

I was not refering to RCS files concretely, but to a hypothetical 
file format which changes almost at every version of the software, 
something that might happen, perhaps in a less dramatic way, if more 
extensions like CommitID are going to be added in the future.  

> 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 guess to keep upward compatibility with new versions of rcs in the 
past.  If it was there for arbitrary use, there would surely be some 
interface to specify them.

> Incrementally adding a new feature is a lot less of a change, and a lot less
> drastic, than switching to an entirely new system.

A program whose file formats keep changing incrementally (and thus 
all the time) causes a feeling of uncertainity.  If I do a drastic 
change on the other hand, I at least know what I get and I can try 
before.  If I am forced to update CVS because of a security problem 
and I notice suddenly it has some unexpected 'incrementally added 
feature', this is not least astonishing.

> 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? 

It is something different if a feature is added within the existing 
specification for the interface and the file formats, or if the 
specification is being changed itself.

But yes, I am saying a program should stick to interface and file 
formats if at all possible.  Today's programs are unfortunately 
changing these much too often and are causing major headaches to a 
lot of users and very many hours wasted of lifetime.  

Just see TeX.  Without doubt, and you will surely agree, one of the 
best programs, perhaps the best program, ever written.  But a big 
part of its success is that features were added carefully and it has 
now come to a point where it is not going to be changed anymore 
except for very cruical bug fixes--it is a safe basis to do work 
with.

> > 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.

I didn't say it should go definitively.  But it must be questioned 
and discussed!

> > It is much better to use the loginfo feature [...]
> For what definition of "better"? Better for _you_, perhaps, but not for the
> dozens or hundreds of users (like me) who _want_ this feature.

It is perhaps not better for these hundreds of users who want such a 
feature quickly, without any further efforts other than updating cvs 
and no matter how implemented, I agree.

But it is better concerning time and network bandwidth wasted.  I do 
not want to do a scan trough all files in my project just to find out 
which files were changed in a commit.  And it is better in that it is 
entirely independent from a change CVS itself. 

> 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. 

I agree this is not an option, but I never imagined it should work 
like this.

> 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. 

It's easy to write a script which saves the input and invokes all 
loginfo scripts one wants to execute on this input in the desired 
order.

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

Only one file has to be read if one wants to retrieve the info, not 
all of them.  The log can be saved together with commitlog.  This 
seems like a good idea to me.  Why exactly do you think it is not a 
good idea?

> 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.

Independent from if this should be encouraged or not, it was the 
solution used by rcsfreeze.  Why exactly wouldn't you encourage it?

> > 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?

I was refering to 'stable' not concerning bugs, but concerning that 
the interfaces and file formats stay the same.  

> 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?

No, but I want at least everyone to have the choice.  My patch didn't 
remove the feature, it made it optional, and it disabled it by 
default, which I think is reasonable given the problems already 
noticed (cvsweb and such).

> 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. 

I have already written that RCS is file based, thus the whole concept 
of a commit ID does not fit into it's concept.

Implementing file permissions, modification time, the current commit 
ID etc. in rcs directly contradicts a very basic, implicit, yet very 
important design decision: To stick writing data into the rcs file 
which can actually be retrieved with the Standard C library.

- Permissions, modification time etc. are POSIX, not Standard C, and 
there are systems where concepts are different or not present.

- the current proposal of Commit ID relies on the concept of seconds 
since epoch, which is also POSIX specific.

So one objective reason is that you cannot do much better than RCS 
already does without loosing an order of magnitude of system 
independency.

> > 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?

Because I don't see any reasons for changing it.  Which reasons do 
*you* see that don't lead to a program substantially similar to 
Subversion?

-- 
Peter 'Rattacresh' Backes, rtc@helen.PLASMA.Xg8.DE