unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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: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  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: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: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  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 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 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"
  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

* 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

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).