* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" @ 2008-08-17 21:12 Bob Rogers 2008-10-03 1:46 ` Glenn Morris 0 siblings, 1 reply; 29+ messages in thread From: Bob Rogers @ 2008-08-17 21:12 UTC (permalink / raw) To: emacs-pretest-bug In trunk updated a few days ago: 0. Identify a version-controlled directory, call it "foo", and create an unregistered file there; call it "bar.text". (Both CVS and SVN work; haven't tried others.) 1. "emacs -Q" in the "foo" directory. 2. "C-x v d RET" will correctly show the file as "unregistered". 3. Delete "foo/bar.text" via dired or in a shell. 4. Type "g" in vc-dir to update. The removed "bar.text" file is now listed incongruously as "up-to-date". Seems to me the "bar.text" line ought to be deleted, or at the very least revert to "unregistered." -- Bob Rogers http://rgrjr.dyndns.org/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-08-17 21:12 bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" Bob Rogers @ 2008-10-03 1:46 ` Glenn Morris 2008-10-03 5:19 ` Dan Nicolaescu 2008-10-04 5:38 ` Dan Nicolaescu 0 siblings, 2 replies; 29+ messages in thread From: Glenn Morris @ 2008-10-03 1:46 UTC (permalink / raw) To: 737; +Cc: Dan Nicolaescu Bob Rogers wrote: > 0. Identify a version-controlled directory, call it "foo", and > create an unregistered file there; call it "bar.text". (Both CVS and > SVN work; haven't tried others.) > > 1. "emacs -Q" in the "foo" directory. > > 2. "C-x v d RET" will correctly show the file as "unregistered". > > 3. Delete "foo/bar.text" via dired or in a shell. > > 4. Type "g" in vc-dir to update. The removed "bar.text" file is now > listed incongruously as "up-to-date". Dan, can you comment on this patch please? Is it correct to assume that a non-existent file described as up-to-date must be a deleted, unregistered one? If not, I guess removing deleted, unregistered files must be done before the call to the backend's dir-status-files function (basically, a version of vc-dir-hide-up-to-date that only removes deleted, unregistered things). It also seems to me that vc-dir-hide-up-to-date should remove deleted unregistered files, hence the change to that function. I'm also unsure if I need to call expand-file-name on the name part at any point... TIA. *** vc-dir.el 25 Aug 2008 15:14:54 -0000 1.22 --- vc-dir.el 3 Oct 2008 01:40:02 -0000 *************** *** 978,985 **** (eq (vc-dir-fileinfo->state info) 'up-to-date)) (setf (vc-dir-fileinfo->state info) nil)) ! ! (not (vc-dir-fileinfo->needs-update info)))))))))))) (defun vc-dir-revert-buffer-function (&optional ignore-auto noconfirm) (vc-dir-refresh)) --- 978,994 ---- (eq (vc-dir-fileinfo->state info) 'up-to-date)) (setf (vc-dir-fileinfo->state info) nil)) ! (unless ! ;; If the file does not exist, but ! ;; is described as up-to-date, it ! ;; can only be an unregistered, ! ;; deleted one (?). ! (and (eq (vc-dir-fileinfo->state info) ! 'up-to-date) ! (not (file-exists-p ! (vc-dir-fileinfo->name info)))) ! (not (vc-dir-fileinfo->needs-update ! info))))))))))))) (defun vc-dir-revert-buffer-function (&optional ignore-auto noconfirm) (vc-dir-refresh)) *************** *** 1064,1070 **** ;; Next item is a directory. (vc-dir-fileinfo->directory (ewoc-data next)))) ;; Remove files in the up-to-date state. ! (eq (vc-dir-fileinfo->state data) 'up-to-date)) (ewoc-delete vc-ewoc crt)) (setq crt prev))))) --- 1073,1082 ---- ;; Next item is a directory. (vc-dir-fileinfo->directory (ewoc-data next)))) ;; Remove files in the up-to-date state. ! (eq (vc-dir-fileinfo->state data) 'up-to-date) ! ;; A file which was deleted without ever being registered. ! (and (eq (vc-dir-fileinfo->state data) 'unregistered) ! (not (file-exists-p (vc-dir-fileinfo->name data))))) (ewoc-delete vc-ewoc crt)) (setq crt prev))))) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-03 1:46 ` Glenn Morris @ 2008-10-03 5:19 ` Dan Nicolaescu 2008-10-03 7:07 ` Glenn Morris 2008-10-04 5:38 ` Dan Nicolaescu 1 sibling, 1 reply; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-03 5:19 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Bob Rogers wrote: > > > 0. Identify a version-controlled directory, call it "foo", and > > create an unregistered file there; call it "bar.text". (Both CVS and > > SVN work; haven't tried others.) > > > > 1. "emacs -Q" in the "foo" directory. > > > > 2. "C-x v d RET" will correctly show the file as "unregistered". > > > > 3. Delete "foo/bar.text" via dired or in a shell. > > > > 4. Type "g" in vc-dir to update. The removed "bar.text" file is now > > listed incongruously as "up-to-date". Does this happen for git? There's a `dir-status-files' VC method that would probably take care of this issue and vc-git.el implements it. > Dan, can you comment on this patch please? Is it correct to assume > that a non-existent file described as up-to-date must be a deleted, > unregistered one? > If not, I guess removing deleted, unregistered files > must be done before the call to the backend's dir-status-files > function (basically, a version of vc-dir-hide-up-to-date that only > removes deleted, unregistered things). I don't think that's good, it would do too many file-exists-p calls in a big directory. > It also seems to me that vc-dir-hide-up-to-date should remove deleted > unregistered files, hence the change to that function. I don't think it should be doing that. > I'm also unsure if I need to call expand-file-name on the name part at > any point... > > TIA. > > > *** vc-dir.el 25 Aug 2008 15:14:54 -0000 1.22 > --- vc-dir.el 3 Oct 2008 01:40:02 -0000 > *************** > *** 978,985 **** > (eq (vc-dir-fileinfo->state info) > 'up-to-date)) > (setf (vc-dir-fileinfo->state info) nil)) > ! > ! (not (vc-dir-fileinfo->needs-update info)))))))))))) > > (defun vc-dir-revert-buffer-function (&optional ignore-auto noconfirm) > (vc-dir-refresh)) > --- 978,994 ---- > (eq (vc-dir-fileinfo->state info) > 'up-to-date)) > (setf (vc-dir-fileinfo->state info) nil)) > ! (unless > ! ;; If the file does not exist, but > ! ;; is described as up-to-date, it > ! ;; can only be an unregistered, > ! ;; deleted one (?). > ! (and (eq (vc-dir-fileinfo->state info) > ! 'up-to-date) > ! (not (file-exists-p > ! (vc-dir-fileinfo->name info)))) > ! (not (vc-dir-fileinfo->needs-update > ! info))))))))))))) > > (defun vc-dir-revert-buffer-function (&optional ignore-auto noconfirm) > (vc-dir-refresh)) > *************** > *** 1064,1070 **** > ;; Next item is a directory. > (vc-dir-fileinfo->directory (ewoc-data next)))) > ;; Remove files in the up-to-date state. > ! (eq (vc-dir-fileinfo->state data) 'up-to-date)) > (ewoc-delete vc-ewoc crt)) > (setq crt prev))))) > > --- 1073,1082 ---- > ;; Next item is a directory. > (vc-dir-fileinfo->directory (ewoc-data next)))) > ;; Remove files in the up-to-date state. > ! (eq (vc-dir-fileinfo->state data) 'up-to-date) > ! ;; A file which was deleted without ever being registered. > ! (and (eq (vc-dir-fileinfo->state data) 'unregistered) > ! (not (file-exists-p (vc-dir-fileinfo->name data))))) > (ewoc-delete vc-ewoc crt)) > (setq crt prev))))) > ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-03 5:19 ` Dan Nicolaescu @ 2008-10-03 7:07 ` Glenn Morris 2008-10-03 19:06 ` Dan Nicolaescu 0 siblings, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-03 7:07 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > Does this happen for git? Sorry, I don't use git, so I don't know. > > It also seems to me that vc-dir-hide-up-to-date should remove deleted > > unregistered files, hence the change to that function. > > I don't think it should be doing that. OK. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-03 7:07 ` Glenn Morris @ 2008-10-03 19:06 ` Dan Nicolaescu 0 siblings, 0 replies; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-03 19:06 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Dan Nicolaescu wrote: > > > Does this happen for git? > > Sorry, I don't use git, so I don't know. I tried and it works. I also implemented the `dir-status-files' method for Mercurial, so this problem should be fixed there too. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-03 1:46 ` Glenn Morris 2008-10-03 5:19 ` Dan Nicolaescu @ 2008-10-04 5:38 ` Dan Nicolaescu 2008-10-05 0:44 ` Glenn Morris 1 sibling, 1 reply; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-04 5:38 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Bob Rogers wrote: > > > 0. Identify a version-controlled directory, call it "foo", and > > create an unregistered file there; call it "bar.text". (Both CVS and > > SVN work; haven't tried others.) > > > > 1. "emacs -Q" in the "foo" directory. > > > > 2. "C-x v d RET" will correctly show the file as "unregistered". > > > > 3. Delete "foo/bar.text" via dired or in a shell. > > > > 4. Type "g" in vc-dir to update. The removed "bar.text" file is now > > listed incongruously as "up-to-date". I've checked in patches to fix this for CVS, Subversion and Mercurial. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-04 5:38 ` Dan Nicolaescu @ 2008-10-05 0:44 ` Glenn Morris 2008-10-05 1:04 ` Dan Nicolaescu 0 siblings, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-05 0:44 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > I've checked in patches to fix this for CVS, Subversion and Mercurial. The subversion one works for me, but the CVS one does not (with vc-stay-local and vc-cvs-stay-local nil). ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 0:44 ` Glenn Morris @ 2008-10-05 1:04 ` Dan Nicolaescu 2008-10-05 1:27 ` Glenn Morris ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-05 1:04 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Dan Nicolaescu wrote: > > > I've checked in patches to fix this for CVS, Subversion and Mercurial. > > The subversion one works for me, but the CVS one does not Do you use a CVS server or a local repository? With a local repository CVS gives different output for unregistered files (it ignores them). > (with vc-stay-local and vc-cvs-stay-local nil). I saw you checked in something to do with that, and now the default behavior for vc-dir is inconsistent with PCL-CVS and tkcvs (and probably all other CVS GUIs): if a file needs merging it says "edited" instead of "needs-merging", if it needs updating it says nothing. IMHO such a change in the default behavior is bad during a feature freeze. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 1:04 ` Dan Nicolaescu @ 2008-10-05 1:27 ` Glenn Morris 2008-10-05 1:45 ` Glenn Morris 2008-10-05 2:24 ` Dan Nicolaescu 2008-10-05 2:17 ` Nick Roberts 2009-01-07 5:33 ` Stefan Monnier 2 siblings, 2 replies; 29+ messages in thread From: Glenn Morris @ 2008-10-05 1:27 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > Do you use a CVS server or a local repository? A server (namely the Emacs server). > I saw you checked in something to do with that, and now the default > behavior for vc-dir is inconsistent with PCL-CVS and tkcvs (and probably > all other CVS GUIs): if a file needs merging it says "edited" instead of > "needs-merging", if it needs updating it says nothing. Those states are impossible (?) to determine without contacting the server. Presumably such inaccuracies are the price people who use stay-local are willing to accept. It sounds like you want vc-dir to ignore vc-stay-local, which I would suggest is something that needs documenting. Or introduce a vc-dir-stay-local, default nil? > IMHO such a change in the default behavior is bad during a feature > freeze. I'm only trying to fix bugs. In this case, #1046. If no-one comments, I do what I think is right. Now you have commented, it can be fixed. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 1:27 ` Glenn Morris @ 2008-10-05 1:45 ` Glenn Morris 2008-10-05 2:01 ` Glenn Morris 2008-10-05 2:24 ` Dan Nicolaescu 1 sibling, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-05 1:45 UTC (permalink / raw) To: Dan Nicolaescu, 737 Glenn Morris wrote (on Sat, 4 Oct 2008 at 21:27 -0400): > Dan Nicolaescu wrote: > > > Do you use a CVS server or a local repository? > > A server (namely the Emacs server). Whoops, I have local changes that may be affecting this. I will rebuild without them... ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 1:45 ` Glenn Morris @ 2008-10-05 2:01 ` Glenn Morris 2008-10-05 15:40 ` Dan Nicolaescu 0 siblings, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-05 2:01 UTC (permalink / raw) To: Dan Nicolaescu, 737 Glenn Morris wrote (on Sat, 4 Oct 2008 at 21:45 -0400): > Whoops, I have local changes that may be affecting this. I will rebuild > without them... I am still seeing this problem with CVS. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 2:01 ` Glenn Morris @ 2008-10-05 15:40 ` Dan Nicolaescu 2008-10-05 23:47 ` Glenn Morris 0 siblings, 1 reply; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-05 15:40 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Glenn Morris wrote (on Sat, 4 Oct 2008 at 21:45 -0400): > > > Whoops, I have local changes that may be affecting this. I will rebuild > > without them... > > I am still seeing this problem with CVS. Hmm, OK, I was testing with files several directories deep, and indeed they disappear from that directory, but they just get moved to the top directory. Oops. This patch vs vc-cvs.el 1.149 seems to fix it (sorry, I don't have time to deal with the stay-local breakage). --- vc-cvs.el.~1.149~ 2008-10-04 18:52:44.000000000 -0700 +++ vc-cvs.el 2008-10-05 08:37:30.000000000 -0700 @@ -832,13 +832,14 @@ state." (file nil) (result nil) (missing nil) + (ignore-next nil) (subdir default-directory)) (goto-char (point-min)) (while ;; Look for either a file entry, an unregistered file, or a ;; directory change. (re-search-forward - "\\(^=+\n\\([^=c?\n].*\n\\|\n\\)+\\)\\|\\(\\(^?? .*\n\\)+\\)\\|\\(^cvs status: Examining .*\n\\)" + "\\(^=+\n\\([^=c?\n].*\n\\|\n\\)+\\)\\|\\(\\(^?? .*\n\\)+\\)\\|\\(^cvs status: \\(Examining\\|nothing\\) .*\n\\)" nil t) ;; FIXME: get rid of narrowing here. (narrow-to-region (match-beginning 0) (match-end 0)) @@ -852,6 +853,21 @@ state." (expand-file-name (match-string 1) subdir))) (push (list file 'unregistered) result) (forward-line 1)) + (when (looking-at "cvs status: nothing known about") + ;; We asked about a non existent file. The output looks like this: + + ;; cvs status: nothing known about `lisp/v.diff' + ;; =================================================================== + ;; File: no file v.diff Status: Unknown + ;; + ;; Working revision: No entry for v.diff + ;; Repository revision: No revision control file + ;; + + ;; Due to narrowing in this iteration we only see the "cvs + ;; status:" line, so just set a flag so that we can ignore the + ;; file in the next iteration. + (setq ignore-next t)) ;; A file entry. (when (re-search-forward "^File: \\(no file \\)?\\(.*[^ \t]\\)[ \t]+Status: \\(.*\\)" nil t) (setq missing (match-string 1)) @@ -870,8 +886,10 @@ state." ((string-match "File had conflicts " status-str) 'conflict) ((string-match "Unknown" status-str) 'unregistered) (t 'edited))) - (unless (eq status 'up-to-date) - (push (list file status) result))) + (if ignore-next + (setq ignore-next nil) + (unless (eq status 'up-to-date) + (push (list file status) result)))) (goto-char (point-max)) (widen)) (funcall update-function result)) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 15:40 ` Dan Nicolaescu @ 2008-10-05 23:47 ` Glenn Morris 0 siblings, 0 replies; 29+ messages in thread From: Glenn Morris @ 2008-10-05 23:47 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > This patch vs vc-cvs.el 1.149 seems to fix it Works for me, thanks. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 1:27 ` Glenn Morris 2008-10-05 1:45 ` Glenn Morris @ 2008-10-05 2:24 ` Dan Nicolaescu 2008-10-05 2:10 ` Nick Roberts 2008-10-05 23:43 ` Glenn Morris 1 sibling, 2 replies; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-05 2:24 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Dan Nicolaescu wrote: > > > Do you use a CVS server or a local repository? > > A server (namely the Emacs server). vc-cvs.el version 1.150 works for me with the emacs CVS server (as annonymous user) > > I saw you checked in something to do with that, and now the default > > behavior for vc-dir is inconsistent with PCL-CVS and tkcvs (and probably > > all other CVS GUIs): if a file needs merging it says "edited" instead of > > "needs-merging", if it needs updating it says nothing. > > Those states are impossible (?) to determine without contacting the > server. Presumably such inaccuracies are the price people who use > stay-local are willing to accept. > > It sounds like you want vc-dir to ignore vc-stay-local, which I would > suggest is something that needs documenting. I just don't think it should be the default. I do think that it's fundamentally broken, so I don't want to have anything to do with it. > Or introduce a vc-dir-stay-local, default nil? I'd prefer it *stay-local would not pollute vc-dir.el, none of the modern VC systems needs it, so there's no good reason to deal with it in the future. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 2:24 ` Dan Nicolaescu @ 2008-10-05 2:10 ` Nick Roberts 2008-10-05 23:43 ` Glenn Morris 1 sibling, 0 replies; 29+ messages in thread From: Nick Roberts @ 2008-10-05 2:10 UTC (permalink / raw) To: Dan Nicolaescu, 737 > > It sounds like you want vc-dir to ignore vc-stay-local, which I would > > suggest is something that needs documenting. > > I just don't think it should be the default. I do think that it's > fundamentally broken, so I don't want to have anything to do with it. It might be sensible to make vc-stay-local default to nil but to just ignore it will only confuse users. > > Or introduce a vc-dir-stay-local, default nil? > > I'd prefer it *stay-local would not pollute vc-dir.el, none of the > modern VC systems needs it, so there's no good reason to deal with it in > the future. We've been here before and some of us said that we found vc-stay-local useful. There are probably many users, RMS included, who don't have permanent or fast access to the Internet. I think that's a good reason to deal with it. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 2:24 ` Dan Nicolaescu 2008-10-05 2:10 ` Nick Roberts @ 2008-10-05 23:43 ` Glenn Morris 2008-10-06 0:33 ` Dan Nicolaescu 1 sibling, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-05 23:43 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > I just don't think it should be the default. I do think that it's > fundamentally broken, so I don't want to have anything to do with it. > > > Or introduce a vc-dir-stay-local, default nil? > > I'd prefer it *stay-local would not pollute vc-dir.el, none of the > modern VC systems needs it, so there's no good reason to deal with it in > the future. As a user of older version control systems, I can't help but feel disenfranchised. I see these options: 1) Take out the checks for stay-local I added recently; vc-dir will always contact the server. Which is fine if you want to argue that this is a new feature, but I will file a wishlist bug to have similar behaviour re-added at some later date. 2) Add a vc-dir-stay-local, default nil, which overrides the others. 3) Change the defaults of vc-stay-local and friends to be nil. 4) Leave as at present, on the assumption that people understand that vc-stay-local et al mean sacrificing accuracy for other gains. It's probably too late for 3) for 23.1. You seem to be set against 2). That doesn't leave much. Anyway, you wrote vc-dir. What would you like me to do? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 23:43 ` Glenn Morris @ 2008-10-06 0:33 ` Dan Nicolaescu 2008-10-06 6:26 ` Nick Roberts 2008-10-06 7:33 ` Glenn Morris 0 siblings, 2 replies; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-06 0:33 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Dan Nicolaescu wrote: > > > I just don't think it should be the default. I do think that it's > > fundamentally broken, so I don't want to have anything to do with it. > > > > > Or introduce a vc-dir-stay-local, default nil? > > > > I'd prefer it *stay-local would not pollute vc-dir.el, none of the > > modern VC systems needs it, so there's no good reason to deal with it in > > the future. > > As a user of older version control systems, I can't help but feel > disenfranchised. > > I see these options: > > 1) Take out the checks for stay-local I added recently; vc-dir will > always contact the server. Which is fine if you want to argue that > this is a new feature, but I will file a wishlist bug to have similar > behaviour re-added at some later date. Note that I only said that this is a bad default. Being inconsistent with all other similar tools (and hence user expectations) by default is wrong. The reason a single person asked about this is to be able to use CVS offline. But vc-dir is useless with CVS offline, it will just tell you that you have edited some files, you can't do any interesting operations. > 2) Add a vc-dir-stay-local, default nil, which overrides the others. I would object to anything in vc-dir that deals with this. vc-dir is new code, it should not be saddled with stuff that will be unused in a few years. Here's an analogy: we have code in vc that deals with automatically checking out RCS files if they don't exist. How many people care about that? But the code is still there and runs by default. I don't want to be stuck with this in vc-dir until the end of time. More, this can all be done in the CVS VC backend. No reason to pollute the vc-dir core with this stuff. It is even possible to add a CVS specific menu entry with a radio button to the VC-dir backend to toggle between the behaviors. > 3) Change the defaults of vc-stay-local and friends to be nil. > > 4) Leave as at present, on the assumption that people understand that > vc-stay-local et al mean sacrificing accuracy for other gains. That would be bad, things were working much better for the majority of people before the change. > It's probably too late for 3) for 23.1. You seem to be set against 2). > That doesn't leave much. > > Anyway, you wrote vc-dir. What would you like me to do? Please change the default to do what it did before. I have no opinion on what to do about switching between the 2 behaviors as long as it does not touch vc-dir.el. Thanks ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-06 0:33 ` Dan Nicolaescu @ 2008-10-06 6:26 ` Nick Roberts 2008-10-06 7:33 ` Glenn Morris 1 sibling, 0 replies; 29+ messages in thread From: Nick Roberts @ 2008-10-06 6:26 UTC (permalink / raw) To: Dan Nicolaescu, 737 > > 4) Leave as at present, on the assumption that people understand that > > vc-stay-local et al mean sacrificing accuracy for other gains. > > That would be bad, things were working much better for the majority of > people before the change. I don't know why you think you speak for the majority as I not noticed anyone share that opinion, but I favour this option. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-06 0:33 ` Dan Nicolaescu 2008-10-06 6:26 ` Nick Roberts @ 2008-10-06 7:33 ` Glenn Morris 2008-10-06 7:53 ` Dan Nicolaescu 1 sibling, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-06 7:33 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > Note that I only said that this is a bad default. > Being inconsistent with all other similar tools (and hence user > expectations) by default is wrong. Traditionally this argument has cut very little ice in Emacs. > That would be bad, things were working much better for the majority of > people before the change. There is no data on this; but I certainly respect your opinion as the author of vc-dir. > Please change the default to do what it did before. I have no > opinion on what to do about switching between the 2 behaviors as > long as it does not touch vc-dir.el. The only way I see to do this and comply with your restrictions is to add something like vc-cvs-dir-stay-local (yuck), default nil; or remove this feature altogether. Svn currently does not contact the repository by default, which is how it was before my changes too. Do you want any changes making there? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-06 7:33 ` Glenn Morris @ 2008-10-06 7:53 ` Dan Nicolaescu 2008-10-06 9:12 ` Nick Roberts 0 siblings, 1 reply; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-06 7:53 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 Glenn Morris <rgm@gnu.org> writes: > Dan Nicolaescu wrote: > > > That would be bad, things were working much better for the majority of > > people before the change. > > There is no data on this; There is, I got many emails from people liking the backend, and suggesting fixes and improvements. On the other hand, there was exactly one person asking for the current default behavior. > but I certainly respect your opinion as the author of vc-dir. Thank you. > > Please change the default to do what it did before. I have no > > opinion on what to do about switching between the 2 behaviors as > > long as it does not touch vc-dir.el. > > The only way I see to do this and comply with your restrictions is to > add something like vc-cvs-dir-stay-local (yuck), default nil; or > remove this feature altogether. The former sounds good to me, if people want this behavior, they can write elisp to set the variable. > Svn currently does not contact the repository by default, which is how > it was before my changes too. Do you want any changes making there? So you mean you did not change the default? (I haven't looked at the svn changes). If you want to make sure TRT happens, please ask Tom Tromey, he wrote that code and AFAIK he uses it daily for real work on big source trees. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-06 7:53 ` Dan Nicolaescu @ 2008-10-06 9:12 ` Nick Roberts 2008-10-08 7:43 ` Glenn Morris 0 siblings, 1 reply; 29+ messages in thread From: Nick Roberts @ 2008-10-06 9:12 UTC (permalink / raw) To: Dan Nicolaescu, 737 > ...On the other hand, there was exactly > one person asking for the current default behavior. Assuming that I'm the one constantly referred to in the third person in your e-mails, note that in reply to one of your earlier e-mails, Stefan Monnier said this: I disagree. The "stay-local" should be the default. It is tremendously useful (think of the case where you're not connected to your repository). The non-stay-local behavior is the one whose usefulness is debatable (after all, most new VCS don't bother offering a clean equivalent). (http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00239.html) There may have been others who disagreed with you but, in any case, it's certainly not "exactly one". Your intolerance of other points of view diminishes the value of the significant contribution that you have made. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-06 9:12 ` Nick Roberts @ 2008-10-08 7:43 ` Glenn Morris 2008-10-09 4:52 ` Dan Nicolaescu 0 siblings, 1 reply; 29+ messages in thread From: Glenn Morris @ 2008-10-08 7:43 UTC (permalink / raw) To: Nick Roberts; +Cc: Dan Nicolaescu, 737 Nick Roberts wrote: > (http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00239.html) From reading that thread, it seems to me that this discussion has already happened, and that the current behaviour is the one Stefan wants, so I'll defer to him. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-08 7:43 ` Glenn Morris @ 2008-10-09 4:52 ` Dan Nicolaescu 2008-10-10 1:39 ` Glenn Morris 2009-01-07 5:30 ` Stefan Monnier 0 siblings, 2 replies; 29+ messages in thread From: Dan Nicolaescu @ 2008-10-09 4:52 UTC (permalink / raw) To: Glenn Morris; +Cc: 737 It's s very sad, but I have to remind you that this was not done the proper way: this code has a clear author and an active maintainer, usually it's nice to ask about making changes to such code. That has not happened, the onus to ask and motivate changes is on the person that makes changes. Changing defaults that actually take functionality away is not a good idea, even a worse idea during a feature freeze. From the discussion here, there's no sign that there was any analysis of the consequences to the end user and ease of use of changing the defaults. So given that I wrote the code in question, and the package that uses it, I will add a new defcustom to control this behavior, and make the default be like before your change. Glenn Morris <rgm@gnu.org> writes: > Nick Roberts wrote: > > > (http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg00239.html) > From reading that thread, it seems to me that this discussion has > already happened, and that the current behaviour is the one Stefan > wants, so I'll defer to him. What Stefan wanted was predicated by the existence of a vc-pull function to balance for not being able to see the status of the remote files. Such a function does not exist, and it probably won't during the feature freeze. Yes, he does have the authority to override anyone, but I hope he will be a bit more tactful in using that power. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-09 4:52 ` Dan Nicolaescu @ 2008-10-10 1:39 ` Glenn Morris 2009-01-07 5:30 ` Stefan Monnier 1 sibling, 0 replies; 29+ messages in thread From: Glenn Morris @ 2008-10-10 1:39 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 Dan Nicolaescu wrote: > It's s very sad, but I have to remind you that this was not done the > proper way: this code has a clear author and an active maintainer, > usually it's nice to ask about making changes to such code. I made the mistake of trying to fix some bugs that were going unanswered, and got sucked into I'm not sure what. Rest assured, I won't make the mistake of touching anything vc-dir related again. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-09 4:52 ` Dan Nicolaescu 2008-10-10 1:39 ` Glenn Morris @ 2009-01-07 5:30 ` Stefan Monnier 2009-01-07 19:35 ` Dan Nicolaescu 1 sibling, 1 reply; 29+ messages in thread From: Stefan Monnier @ 2009-01-07 5:30 UTC (permalink / raw) To: 737 > The reason a single person asked about this is to be able to use CVS > offline. But vc-dir is useless with CVS offline, it will just tell you Actually, the stay-local feature in CVS is (for me) not so much to work offline (since CVS is not really usable in that circumstance), but so that M-x vc-dir RET doesn't take ages to give me a buffer. I very often want to have a *vc-dir* buffer to see which files I've modified, then either open them, or get a diff of the changes I made, ... all those operations can be made in much less time than it takes for "cvs update -n" (or "cvs status") to finish. Supposedly, those operations can even all be performed offline in Svn, so stay-local might be even more useful there. > What Stefan wanted was predicated by the existence of a vc-pull function > to balance for not being able to see the status of the remote > files. Actually, vc-pull is not just needed to make up for "stay-local". It's just needed for all the more modern backends. So it's a high priority. > Such a function does not exist, and it probably won't during the > feature freeze. Yes, it's too bad that vc-dir is still lacking such features at this point. Not enough contributors, it seems. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2009-01-07 5:30 ` Stefan Monnier @ 2009-01-07 19:35 ` Dan Nicolaescu 2009-01-08 16:44 ` Stefan Monnier 0 siblings, 1 reply; 29+ messages in thread From: Dan Nicolaescu @ 2009-01-07 19:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: 737 Stefan Monnier <monnier@iro.umontreal.ca> writes: > > The reason a single person asked about this is to be able to use CVS > > offline. But vc-dir is useless with CVS offline, it will just tell you > > Actually, the stay-local feature in CVS is (for me) not so much to work > offline (since CVS is not really usable in that circumstance), but so > that M-x vc-dir RET doesn't take ages to give me a buffer. I very often > want to have a *vc-dir* buffer to see which files I've modified, then > either open them, or get a diff of the changes I made, ... all those > operations can be made in much less time than it takes for "cvs > update -n" (or "cvs status") to finish. Wow, this answer is a blast from the past... You can get the above by setting a variable, doing it by default for CVS does not seem like a good idea. > Supposedly, those operations can even all be performed offline in Svn, > so stay-local might be even more useful there. > > > What Stefan wanted was predicated by the existence of a vc-pull function > > to balance for not being able to see the status of the remote > > files. > > Actually, vc-pull is not just needed to make up for "stay-local". > It's just needed for all the more modern backends. So it's > a high priority. > > > Such a function does not exist, and it probably won't during the > > feature freeze. > > Yes, it's too bad that vc-dir is still lacking such features at > this point. Not enough contributors, it seems. You are giving vc-dir too much credit here, in itself it's nothing more than a pretty printer and a GUI that can return multiple selections. What's missing is the mechanism to do these things in VC. Once VC has support for vc-pull, adding such support to vc-dir should be easy. It's strange that VC does not get more contributors. It might be because people think that VC is not good enough, but now that should not be the case anymore, since it can do operations on multiple files/directories it's in a decent shape. Or maybe people think that VC is too complex (I certainly thought so until I first looked at it), but it's really not, once you look underneath it's pretty straightforward. It's even more strange that version control is so important nowadays, and just about everyone seems to have a very strong opinion about it, but not enough to want to contribute to VC... Maybe you want to make some public statement saying that VC is in good shape now, and that contributions to improve it are welcome and very much wanted... ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2009-01-07 19:35 ` Dan Nicolaescu @ 2009-01-08 16:44 ` Stefan Monnier 0 siblings, 0 replies; 29+ messages in thread From: Stefan Monnier @ 2009-01-08 16:44 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: 737 >> Actually, the stay-local feature in CVS is (for me) not so much to work >> offline (since CVS is not really usable in that circumstance), but so >> that M-x vc-dir RET doesn't take ages to give me a buffer. I very often >> want to have a *vc-dir* buffer to see which files I've modified, then >> either open them, or get a diff of the changes I made, ... all those >> operations can be made in much less time than it takes for "cvs >> update -n" (or "cvs status") to finish. > Wow, this answer is a blast from the past... Yes, I was going through some forgotten old emails. > You can get the above by setting a variable, doing it by default for CVS > does not seem like a good idea. Good, thanks. >> Yes, it's too bad that vc-dir is still lacking such features at >> this point. Not enough contributors, it seems. > You are giving vc-dir too much credit here, in itself it's nothing more > than a pretty printer and a GUI that can return multiple selections. > What's missing is the mechanism to do these things in VC. Once VC has > support for vc-pull, adding such support to vc-dir should be easy. I guess you're right, but I don't see VC and vc-dir as so separate. Especially not for vc-pull since it would (most likely) only/mostly be available through vc-dir. > Maybe you want to make some public statement saying that VC is in good > shape now, and that contributions to improve it are welcome and very > much wanted... Of course, now that we're in feature freeze, it's kind of ill-timed. Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 1:04 ` Dan Nicolaescu 2008-10-05 1:27 ` Glenn Morris @ 2008-10-05 2:17 ` Nick Roberts 2009-01-07 5:33 ` Stefan Monnier 2 siblings, 0 replies; 29+ messages in thread From: Nick Roberts @ 2008-10-05 2:17 UTC (permalink / raw) To: Dan Nicolaescu, 737 > I saw you checked in something to do with that, and now the default > behavior for vc-dir is inconsistent with PCL-CVS and tkcvs (and probably > all other CVS GUIs): if a file needs merging it says "edited" instead of > "needs-merging", if it needs updating it says nothing. Is vc-dir with PCL-CVS a fair comparison? The latter only works with CVS while the former works with many version control systems. > IMHO such a change in the default behavior is bad during a feature > freeze. I think that it's more accurate to say that vc-dir replaces vc-directory. In which case Glenn's patch doesn't change the default behavior but fixes broken behavior. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" 2008-10-05 1:04 ` Dan Nicolaescu 2008-10-05 1:27 ` Glenn Morris 2008-10-05 2:17 ` Nick Roberts @ 2009-01-07 5:33 ` Stefan Monnier 2 siblings, 0 replies; 29+ messages in thread From: Stefan Monnier @ 2009-01-07 5:33 UTC (permalink / raw) To: 737 > I saw you checked in something to do with that, and now the default > behavior for vc-dir is inconsistent with PCL-CVS and tkcvs (and probably > all other CVS GUIs): if a file needs merging it says "edited" instead of > "needs-merging", if it needs updating it says nothing. Note also that this behavior is maybe inconsistent with tkCVS and cvs-examine, but it's not only consistent with cvs-quickdir but also it's consistent with vc-dir used on Arch, Git, Bzr, Hg, ... Stefan ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2009-01-08 16:44 UTC | newest] Thread overview: 29+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-08-17 21:12 bug#737: vc-dir reports unregistered-then-deleted file is "up-to-date" Bob Rogers 2008-10-03 1:46 ` Glenn Morris 2008-10-03 5:19 ` Dan Nicolaescu 2008-10-03 7:07 ` Glenn Morris 2008-10-03 19:06 ` Dan Nicolaescu 2008-10-04 5:38 ` Dan Nicolaescu 2008-10-05 0:44 ` Glenn Morris 2008-10-05 1:04 ` Dan Nicolaescu 2008-10-05 1:27 ` Glenn Morris 2008-10-05 1:45 ` Glenn Morris 2008-10-05 2:01 ` Glenn Morris 2008-10-05 15:40 ` Dan Nicolaescu 2008-10-05 23:47 ` Glenn Morris 2008-10-05 2:24 ` Dan Nicolaescu 2008-10-05 2:10 ` Nick Roberts 2008-10-05 23:43 ` Glenn Morris 2008-10-06 0:33 ` Dan Nicolaescu 2008-10-06 6:26 ` Nick Roberts 2008-10-06 7:33 ` Glenn Morris 2008-10-06 7:53 ` Dan Nicolaescu 2008-10-06 9:12 ` Nick Roberts 2008-10-08 7:43 ` Glenn Morris 2008-10-09 4:52 ` Dan Nicolaescu 2008-10-10 1:39 ` Glenn Morris 2009-01-07 5:30 ` Stefan Monnier 2009-01-07 19:35 ` Dan Nicolaescu 2009-01-08 16:44 ` Stefan Monnier 2008-10-05 2:17 ` Nick Roberts 2009-01-07 5:33 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).