Re: Patch for making CommitID configurable

[Peter Backes]

On 26 Apr 2005 at 0:25, Mark D. Baushke wrote:

> Derek Price <derek@ximbiot.com> 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, rtc@helen.PLASMA.Xg8.DE