8:18 a.m.
Hi.
When an empty .cvsrc is found all the pcl-cvs standard args are set to
empty. I don't consider this the right behaviour.
I think it should be as follows:
1) if there are arguments found .cvsrc use those
1a) special case: If a command is found in .cvsrc with no arguments
then use no arguments for that command
2) for those commands that is *not* configured in .cvsrc use pcl-cvs
original defaults.
Comments on this behaviour is welcome.
To provoke the situation create an empty .cvsrc and compare behaviour
of (say diff `=' in cvs-mode ) to the situation where .cvsrc does not exist.
I have made a patch to fix this, but it still need some work, since
re-reading of .cvsrc will not reset the pcl-<command>-flags to the
original defaults initialised with
`(cvs-flags-define cvs-<command>-flags (cvs-defaults LIST))'
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/pcl-cvs/pcl-cvs.el,v
retrieving revision 2.39
diff -u -r2.39 pcl-cvs.el
--- pcl-cvs/pcl-cvs.el 2001/12/21 06:25:16 2.39
+++ pcl-cvs/pcl-cvs.el 2002/01/22 08:22:11
＠＠ -118,10 +118,18 ＠＠
(dolist (cmd '("cvs" "checkout" "status"
"log" "diff" "tag"
"add" "commit" "remove" "update"))
(let* ((sym (intern (concat "cvs-" cmd "-flags")))
- (val (when (string-match (concat "^" cmd "\\s-\\(.*\\)$")
cvsrc)
- (cvs-string->strings (match-string 1 cvsrc)))))
- (cvs-flags-set sym 0 val)))
- ;; ensure that cvs doesn't have -q or -Q
+ (params (when (string-match (concat "^" cmd
"\\(\\s-+\\(.*\\)\\)?$") cvsrc)
+ (cvs-string->strings (or (match-string 2 cvsrc)
""))
+ )))
+ (if params
+ (cvs-flags-set sym 0 (if (equal params '("")) nil params ))
+ ;;FIXME: Otherwise set the flags to the original pcl-cvs
+ ;;default params here in the else part. /jarl
+ )
+ ))
+ ;; Ensure that cvs doesn't have -q or -Q and ensure to have the -f
+ ;; FIXME: several invokes of `cvs-reread-cvsrc' will have many
+ ;; "-f" options, this doesn't hurt but it's not beautiful. /jarl
(cvs-flags-set 'cvs-cvs-flags 0
(cons "-f"
(cdr (cvs-partition
===================================================================
12:27 p.m.
New subject: [PATCH] Re: pcl-cvs patch
SUPERSEDES
As a first-time patcher I hope it's acceptable with my newbieness
behaviour. I probably shouldn't cross-post a patch (but only to
patches) but since I should do a follow-up to my previous incorrect
posting, I guess this is the less confussing. Next time I hope I am
able to just send *one* patch to patches＠ and I will try to use patcher then.
An entry for the ChangeLog:
2002-01-22 Jarl Friis <jarl(a)diku.dk>
* 20 (pcl-cvs.el): using default parameters for cvs-commands
not listed in ~/.cvsrc
pcl-cvs Patch (cvs -q diff -u pcl-cvs.el):
Index: pcl-cvs.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/xemacs-packages/pcl-cvs/pcl-cvs.el,v
retrieving revision 2.39
diff -u -u -r2.39 pcl-cvs.el
--- pcl-cvs.el 2001/12/21 06:25:16 2.39
+++ pcl-cvs.el 2002/01/22 12:20:01
＠＠ -118,10 +118,18 ＠＠
(dolist (cmd '("cvs" "checkout" "status"
"log" "diff" "tag"
"add" "commit" "remove" "update"))
(let* ((sym (intern (concat "cvs-" cmd "-flags")))
- (val (when (string-match (concat "^" cmd "\\s-\\(.*\\)$")
cvsrc)
- (cvs-string->strings (match-string 1 cvsrc)))))
- (cvs-flags-set sym 0 val)))
- ;; ensure that cvs doesn't have -q or -Q
+ (params (when (string-match (concat "^" cmd
"\\(\\s-+\\(.*\\)\\)?$") cvsrc)
+ (cvs-string->strings (or (match-string 2 cvsrc)
""))
+ )))
+ (if params
+ (cvs-flags-set sym 0 (if (equal params '("")) nil params ))
+ ;;FIXME: Otherwise set the flags to the original pcl-cvs
+ ;;default params here in the else part. /jarl
+ )
+ ))
+ ;; Ensure that cvs doesn't have -q or -Q and ensure to have the -f
+ ;; FIXME: several invokes of `cvs-reread-cvsrc' will have many
+ ;; "-f" options, this doesn't hurt but it's not beautiful. /jarl
(cvs-flags-set 'cvs-cvs-flags 0
(cons "-f"
(cdr (cvs-partition
4:07 a.m.
New subject: Patch ettiquette [was: [PATCH] Re: pcl-cvs patch
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> As a first-time patcher I hope it's acceptable with my
Jarl> newbieness behaviour. I probably shouldn't cross-post a
Jarl> patch (but only to patches)
Don't worry about it. XEmacs is in your debt for your efforts, not
the other way around. Thanks for your patches! :-)
If you intend a patch for _application_ to the sources as is, _always_
post it to xemacs-patches, even if there are minor points you are
asking for discussion about. Not doing so will resulting in patches
getting "lost". If you expect that the patch will not be acceptable,
but are using it to stimulate discussion, then don't post to
xemacs-patches. Intermediate cases are up to your judgement; unless
you're sure you'll followup with a "real" patch, better to err on the
side of posting to xemacs-patches.
Discussion of the _content_ of the patch (ie responses to reviewer
comments beyond "that's right, ok, I'll do it your way") should
_always_
be posted to xemacs-beta. (We may split xemacs-beta into code
discussion and stuff that is more relevant to non-developer testers at
some point, but at this point xemacs-beta is the correct place for
this.)
These rules will result in a fair number of cross posts, but we don't
yet have a better way to handle that.
Note: Developers should never post to xemacs-patches unless there is a
patch in the post. We plan to enforce this with an automatic filter.
The exceptions are administrative. If you have commit authorization,
then post a short COMMIT notice to xemacs-patches when you commit to
CVS. Menbers of the Review Board will also post short notices of
administrative action (APPROVE, VETO, QUERY, etc) to xemacs-patches.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
7:46 a.m.
New subject: Patch ettiquette [was: [PATCH] Re: pcl-cvs patch
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Jarl" == Jarl Friis
<jarl(a)diku.dk> writes:
Jarl> As a first-time patcher I hope it's acceptable with my
Jarl> newbieness behaviour. I probably shouldn't cross-post a
Jarl> patch (but only to patches)
Don't worry about it. XEmacs is in your debt for your efforts, not
the other way around. Thanks for your patches! :-)
If you intend a patch for _application_ to the sources as is, _always_
post it to xemacs-patches, even if there are minor points you are
asking for discussion about. Not doing so will resulting in patches
getting "lost". If you expect that the patch will not be acceptable,
but are using it to stimulate discussion, then don't post to
xemacs-patches. Intermediate cases are up to your judgement; unless
you're sure you'll followup with a "real" patch, better to err on the
side of posting to xemacs-patches.
Discussion of the _content_ of the patch (ie responses to reviewer
comments beyond "that's right, ok, I'll do it your way") should
_always_
be posted to xemacs-beta. (We may split xemacs-beta into code
discussion and stuff that is more relevant to non-developer testers at
some point, but at this point xemacs-beta is the correct place for
this.)
These rules will result in a fair number of cross posts, but we don't
yet have a better way to handle that.
Note: Developers should never post to xemacs-patches unless there is a
patch in the post. We plan to enforce this with an automatic filter.
The exceptions are administrative. If you have commit authorization,
then post a short COMMIT notice to xemacs-patches when you commit to
CVS. Menbers of the Review Board will also post short notices of
administrative action (APPROVE, VETO, QUERY, etc) to xemacs-patches.
Thank you very much Stephen, I really found the information useful. My
next patch may eventually be to include some of your
explanation/distinction of xemacs-beta vs. xemacs-patches into the text
found when hitting M-x describe-beta, hope you don't mind that ;-)
Jarl
9:19 a.m.
New subject: Patch ettiquette [was: [PATCH] Re: pcl-cvs patch
>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk>
writes:
Jarl> Thank you very much Stephen, I really found the information
Jarl> useful. My next patch may eventually be to include some of
Jarl> your explanation/distinction of xemacs-beta
Jarl> vs. xemacs-patches into the text found when hitting M-x
Jarl> describe-beta, hope you don't mind that ;-)
Er, besides the embarrassment of failing to do it myself already, no.
On second thought, embarrass me more!! :-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
8122
days inactive
8123
days old
4 comments
2 participants
participants (2)
-
Jarl Friis -
Stephen J. Turnbull