[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Patch for making CommitID configurable
RE: Patch for making CommitID configurable
Wed, 27 Apr 2005 01:20:43 +0200
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?
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
> > 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
> > 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
I agree this is not an option, but I never imagined it should work
> 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
> - 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
> 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
> > 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
Peter 'Rattacresh' Backes, rtc@helen.PLASMA.Xg8.DE
RE: Patch for making CommitID configurable, Jim.Hyslop, 2005/04/26
- Re: Patch for making CommitID configurable, (continued)
- Re: Patch for making CommitID configurable, Derek Price, 2005/04/27
- Re: Patch for making CommitID configurable, Mark D. Baushke, 2005/04/27
- Re: Patch for making CommitID configurable, Peter Backes, 2005/04/27
- Re: Patch for making CommitID configurable, Derek Price, 2005/04/26
- Re: Patch for making CommitID configurable, Mark D. Baushke, 2005/04/26
RE: Patch for making CommitID configurable, Jim.Hyslop, 2005/04/27
RE: Patch for making CommitID configurable, Torsten Martinsen, 2005/04/28
- RE: Patch for making CommitID configurable,
Peter Backes <=