vc-dir with Subversion

vc-dir with Subversion

[Nick Roberts]

In the past I've remarked that with CVS vc-dir ignores vc-stay-local (and
vc-cvs-stay-local) and consults the repository, in any case.

I now see that with SVN, vc-dir also ignores vc-stay-local but this time
never consults the repository.

I'm not sure if it worked with vc-directory, but for this function, the
command "svn log -u" was used when vc-stay-local was nil.  In Emacs 23.0.60
it always just sends "svn log"

-- 
Nick                                           http://www.inet.net.nz/~nickrob

vc-dir with Subversion

[Nick Roberts]

Using Subversion, vc-dir detects conflicts of two kinds:

1) Prior to updating.
2) After updating.

but labels the status with the keyword `conflict' in both cases.  In the
latter case all other keywords use the past tense: removed, edited,
unregistered etc.  To avoid confusion I suggest that we use the keyword
`conflicted' for this case.  The patch below does this.

OK to apply?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2009-04-03  Nick Roberts  <nickrob@snap.net.nz>

	* vc-svn.el (vc-svn-after-dir-status): Use "conflicted" for a file
	with conflicts in it.

	* vc-dir.el (vc-default-dir-printer): Use font-lock-warning-face
	for keyword above.


*** vc-svn.el.~1.112.~	2009-02-10 18:59:14.000000000 +1300
--- vc-svn.el	2009-04-03 20:39:29.000000000 +1300
*************** want to force an empty list of arguments
*** 156,162 ****
  ;; but to distinguish the two output formats based on content.
  (defun vc-svn-after-dir-status (callback &optional remote)
    (let ((state-map '((?A . added)
!                      (?C . conflict)
                       (?D . removed)
                       (?I . ignored)
                       (?M . edited)
--- 156,162 ----
  ;; but to distinguish the two output formats based on content.
  (defun vc-svn-after-dir-status (callback &optional remote)
    (let ((state-map '((?A . added)
!                      (?C . conflicted)
                       (?D . removed)
                       (?I . ignored)
                       (?M . edited)


*** vc-dir.el.~1.38.~	2009-03-21 09:41:38.000000000 +1300
--- vc-dir.el	2009-04-03 20:41:57.000000000 +1300
*************** Interactively, a prefix argument means t
*** 1171,1177 ****
       (propertize
        (format "%-20s" state)
        'face (cond ((eq state 'up-to-date) 'font-lock-builtin-face)
! 		  ((memq state '(missing conflict)) 'font-lock-warning-face)
  		  (t 'font-lock-variable-name-face))
        'mouse-face 'highlight)
       " "
--- 1171,1177 ----
       (propertize
        (format "%-20s" state)
        'face (cond ((eq state 'up-to-date) 'font-lock-builtin-face)
! 		  ((memq state '(missing conflict conflicted)) 'font-lock-warning-face)
  		  (t 'font-lock-variable-name-face))
        'mouse-face 'highlight)
       " "

Re: vc-dir with Subversion

[Richard M Stallman]

    1) Prior to updating.
    2) After updating.

    but labels the status with the keyword `conflict' in both cases.  In the
    latter case all other keywords use the past tense: removed, edited,
    unregistered etc.  To avoid confusion I suggest that we use the keyword
    `conflicted' for this case.  The patch below does this.

The difference between "conflict" and "conflicted" is small.
If this distinction is important, I think it is important to make
it more prominent.

Which of these two cases is a CVS conflict similar to?
I think it is case 2, that a conflict in CVS is reported
after updating.  If that is true, it seems to me that case 2
should be described with "conflict" and case 1 should have
some other name.

Re: vc-dir with Subversion

[Chong Yidong]

nickrob@snap.net.nz (Nick Roberts) writes:

> Using Subversion, vc-dir detects conflicts of two kinds:
>
> 1) Prior to updating.
> 2) After updating.
>
> but labels the status with the keyword `conflict' in both cases.  In the
> latter case all other keywords use the past tense: removed, edited,
> unregistered etc.  To avoid confusion I suggest that we use the keyword
> `conflicted' for this case.

Is there any practical reason for the user to be able to distinguish
between the two states?

Re: vc-dir with Subversion

[Nick Roberts]

Richard M Stallman writes:
 >     1) Prior to updating.
 >     2) After updating.
 > 
 >     but labels the status with the keyword `conflict' in both cases.  In the
 >     latter case all other keywords use the past tense: removed, edited,
 >     unregistered etc.  To avoid confusion I suggest that we use the keyword
 >     `conflicted' for this case.  The patch below does this.
 > 
 > The difference between "conflict" and "conflicted" is small.
 > If this distinction is important, I think it is important to make
 > it more prominent.
 > 
 > Which of these two cases is a CVS conflict similar to?

vc-dir with CVS doesn't recognise the first case and just reports the state
as `needs-merge'.  That's because it uses the command `cvs status' which
doesn't report that therre will be a conflict (it gives "Status: Needs Patch"
in this case.  Interestingly "cvs -n up" does recognise there would be a
conflict in it's output (with the letter `C').

 > I think it is case 2, that a conflict in CVS is reported
 > after updating.  If that is true, it seems to me that case 2
 > should be described with "conflict" and case 1 should have
 > some other name.

It is case 2.  I didn't consider CVS in my e-mail, but I think it would be
more logical to change that case (CVS) to `conflicted'.

Re: vc-dir with Subversion

[Nick Roberts]

Chong Yidong writes:
 > nickrob@snap.net.nz (Nick Roberts) writes:
 > 
 > > Using Subversion, vc-dir detects conflicts of two kinds:
 > >
 > > 1) Prior to updating.
 > > 2) After updating.
 > >
 > > but labels the status with the keyword `conflict' in both cases.  In the
 > > latter case all other keywords use the past tense: removed, edited,
 > > unregistered etc.  To avoid confusion I suggest that we use the keyword
 > > `conflicted' for this case.
 > 
 > Is there any practical reason for the user to be able to distinguish
 > between the two states?

If you see the file is marked with `conflict' and visit the file, sometimes
there are conflict markers present and sometimes there aren't.  I think it's
confusing to mark to different states with the same keyword.

Is there any practical reason for the user *not* to be able to distinguish
between the two states?

-- 
Nick                                           http://www.inet.net.nz/~nickrob