Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Peter Backes wrote:
On 21 Apr 2005 at 10:02, Derek Price wrote:
I really want to make this the default behavior, even after an
upgrade. Would this do the trick for you?
What do you mean exactly? new-use_commit_id = true instead of
false, i.e. have commit IDs written even for old repositories after
an update? I'd not recommend this. It violates the principle of
least astonishment (like the current solution). However, at least it
was better than the current situation.
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. Any dissenting
opinions other than Peter's out there?
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.
Why is RCS whining anyhow? The spec leaves room for newphrases. Is it
requesting an upgrade?
If you pass the -q switch to the RCS 5.7 commands, they will not whine
about unknown phrases. The warning message spews from the
rcs-5.7/src/rcslex.c::warnignore() function which is called from
rcs-5.7/src/rcslex.c::getphrases() when NextString is not one of the
known keywords.
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'
% rlog foo,v
rlog: foo,v: warning: Unknown phrases like `commitid ...;' are present.
...
% rcsdiff -r1.1 -r1.2 foo,v
rcsdiff: foo,v: warning: Unknown phrases like `newphrase ...;' are present.
===
RCS file: foo,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
26a27
#
%
See also the threads here:
http://www.cvsnt.org/pipermail/cvsnt/2003-February/005206.html
http://mailman.lyra.org/pipermail/viewcvs/2003q1/001713.html
http://www.akhphd.au.dk/~bertho/cvsgraph/viewcvs.cgi/cvsgraph/rcsl.l?rev=1.6
One solution might be to modify lib/vclib/bincvs/__init__.py to
use commands like 'co', 'rlog' with different command-line args than
fp = self.rcs_popen('co', (rev_flag, full_name), 'rb')
fp = self.rcs_popen('rlog', args, 'rt', 0)
or the others that exist.
Another alternative might be to provide a patch to the RCS maintainer
to support any of the newphrase formats that CVS has introduced...
Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCbezU3x41pRYZE/gRAq2KAKCg9gtNeRyUVhgA1aSRMlpBL/m1QQCfSHPH
o1NmVR1kyrB/uucNfTBFeTA=
=pUMj
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Patch for making CommitID configurable
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
Re: Patch for making CommitID configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: 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. Okay, but the threads you cite seem to indicate that they have dealt with the problems by passing -q into RCS or tweaking their parsers. I still don't see any reason not to enable commitds by default on feature. Okay. I suppose it may be desirable to make note of the possible problems folks might see if they are using older RCS tools in our CVS documentation, but this thread may be useful enough for that purpose. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCbpW73x41pRYZE/gRAv85AKCxmFJru81qiaSDC29xpQV766+AyACZAcpB 6e3Bpt0FAjp/z0nKbnL/+/4= =p81z -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Patch for making CommitID configurable
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? 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 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! Incrementally adding a new feature is a lot less of a change, and a lot less drastic, than switching to an entirely new system. 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? 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. 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. For what definition of better? Better for _you_, perhaps, but not for the dozens or hundreds of users (like me) who _want_ this feature. 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. 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. - tracking the commit ID in a separate database. Separating the commit information (i.e. the ID and the log) is not a good idea. When does a commit ID make sense? Only in a distributed environment, where a revision must be identified uniquely independent of it's number. Huh? Not! The commit ID allows me to determine which files were committed in a single operation. It has no bearing on distributed environments. I'm looking at a file, and the log says Fixed such-and-such a bug. I want to know what other files were committed at the same time. Currently, I have to rely on narrowing it down by timestamp, using a difficult-to-remember, not very obvious technique for entering timestamps. Or, I could just type in the commitID and there it is. How about tags? Don't they also provide just the solution to the problems commit ID was added for? 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. 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 your point would be... what, exactly? Does RCS not have any kind of a test suite to check for problems? So please don't change rcs anymore except for bug fixes! 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? (that was a rhetorical question, by the way - I'm sure that is not what you intended). 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. 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? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] Improve pam header detection
On 2005/04/26, at 6:52, Mark D. Baushke wrote: Hi Moriyoshi, I have committed your patch to allow --enable-pm to work on MacOS X to the cvshome.org CVS trunk. Thank you for the attention. I'll check out the next release. Moriyoshi ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
