On 26 Apr 2005 at 0:25, Mark D. Baushke wrote: > Derek Price <[EMAIL PROTECTED]> writes: > > I'm not sure I believe that. I think most people would prefer to not > > have to jump through any hoops to see new features enabled, especially > > when dealing with feature releases, and I don't think all that many > > people run RCS inside their CVS repositories anymore.
But if in doubt, just in these sitations the principle of least astonishement gives us the answer! Just think about what *is* the big advantage of CVS besides working on RCS files instead of a strange ever-changing file format? 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! Having said this, it is obvious that it should also be a question of whether CommitID should be kept as a feature *at all*. 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. With a little bit of thinking, you can even find a way to accept the commitlog remotely entirely using existing cvs features! So please think a little bit before using CommitID blindly. When does a commit ID make sense? Only in a distributed environment, where a revision must be identified uniquely independent of it's number. Is the current CommitID usable for this? No, because a collision is not entirely unlikely (commit needs to happen at the same time with the same PID and the same random number, but I only see this to be safe enough to ensure unique IDs for the same machine.) Some well-known commercial SCM for example includes the host name in the ID. Besides that, CVS is currently not distributed at all. And, if I have a certain CommitID and a file that didn't change in this commit, it is impossible to say which revision of the file was actually current at the time of the commit. And isn't the commit time already unique per commit? (If the commit takes longer than a second? Can there be more than one commit per second?) I don't know, but you should check this--it might be just the feature that you now try to implement a second time. How about tags? Don't they also provide just the solution to the problems commit ID was added for? But I don't really know the intentions of the commit ID. What it it's purpose? Maybe I understand it better then. > I am given to understand that WebCVS and ViewCVS can run 'rcs' commands > like rlog as a way to glean information out of the local repository > without running 'cvs' commands on the ,v files. I didn't know about these problems, but it just shows the principle of least astonishement is not misplaced here. If I am in a hurry, and need to update cvs because of the security bug and suddenly my webcvs stops working, this is not how it is supposed to be, is it? > A solution would be to ensure that the '-q' switch is being passed to > any rcs command that might run into a newphrase like 'commitid' That's not a solution; it actually makes things worse! Assumed there is a *real* problem rcs was about to tell me (like a corrpupted ,v file for whatever reason), I'd possibly not notice because of the '- q'. This is like adding casts in C programs just to shut off the compiler. > 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 it operates on *one* file at a time (it can actually process several, but only in a way that is more or less equivalent to a for loop, and this is certainly not to suggest any relationship at all between the files being processed.) I don't see any feature which was not a step backwards that should be added to rcs. So please don't change rcs anymore except for bug fixes! CVS is to be built upon the things given by RCS, not the other way around. Subversion is the better solution to all problems that might make a CommitID reasonable. BTW, what was actually the reason for merging all the tools (rcs, diff3, etc.) into cvs? I think I have read there was something with branches that could not be done by invoking rcs, can you please tell me what this was exactly? Independent from this, I think my patch is a good idea. It leaves the choice to the user. -- Peter 'Rattacresh' Backes, [EMAIL PROTECTED] _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
