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, [EMAIL PROTECTED] _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
