bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Tim Van Holder]

I added a file external to an SVN tree.
Opening the file does not add any SVN information to the mode line,
and operations like [C-x v l] report "File is not under version
control".

svn status reports the file just fine (but with the X in column 5
to indicate that it's an external). Looking at vc-svn-parse-status,
that's the problem - it explicitly ignores files with 'X' markers.

However, if its argument is expected to be a file, not a directory,
I don't think that makes sense. If it's a file inside a directory
external, vc-svn-root would report that directory external, and a status
on it would not include the X (it would only be shown on status output
from above the external).
Changing

    (while (re-search-forward
            ;; Ignore the files with status X.
	    "^\\(?:\\?\\|[ ACDGIMR!~][ MC][ L][ +][ S]..\\([ *]\\) +\\([-0-9]+\\) +\\([0-9?]+\\) +\\([^ ]+\\)\\) +" nil t)

to

    (while (re-search-forward
	    "^\\(?:\\?\\|[ ACDGIMR!~][ MC][ L][ +][ SX]..\\([ *]\\) +\\([-0-9]+\\) +\\([0-9?]+\\) +\\([^ ]+\\)\\) +" nil t)

resolves my issue, but I can't be sure it doesn't cause problems
elsewhere.


In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-25 on trouble, modified by Debian
Windowing system distributor `HC-Consult', version 11.0.11500001
System Description:	Debian GNU/Linux testing (jessie)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums find-func python json
grep compile make-mode diff-mode vc-cvs vc-rcs vc-dir ewoc shell
pcomplete comint ansi-color ring add-log log-view easy-mmode pcvs-util
vc help-mode misearch multi-isearch vc-dispatcher vc-svn cperl-mode
easymenu dired whitespace zastai jka-compr paren gnus gnus-ems nnheader
gnus-util mail-utils mm-util help-fns mail-prsvr wid-edit cl-loaddefs
cl-lib time delsel cus-start cus-load 50magit devhelp time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 162376 11391)
 (symbols 48 24144 0)
 (miscs 40 108 620)
 (strings 32 27856 5500)
 (string-bytes 1 841486)
 (vectors 16 14973)
 (vector-slots 8 442867 10009)
 (floats 8 81 443)
 (intervals 56 5084 590)
 (buffers 960 24)
 (heap 1024 22599 906))

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Stefan Monnier]

> I added a file external to an SVN tree.

I haven't used SVN is many years and have never had to use its externals
support, so I'm not really sure exactly what it does and even less how
it should be supported in VC.

> resolves my issue, but I can't be sure it doesn't cause problems
> elsewhere.

Hopefully someone else knows better, but otherwise I suggest you try to
use this change for a while, testing it with things like
diff/annotate/younameit.

And then report here if you really think that works better.


        Stefan

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Tim Van Holder]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On 6 November 2014 16:46, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > I added a file external to an SVN tree.
>
> I haven't used SVN is many years and have never had to use its externals
> support, so I'm not really sure exactly what it does and even less how
> it should be supported in VC.
>

SVN has two types of externals (both set via svn:externals properties on
directories).
Regular externals (supported for a very long time) pull in external SVN
trees inside your checkout. Because they get their own .svn root, vc-svn
handles these just fine.
File externals (added more recently; in 1.7 I think) allow you to pull in a
single file from elsewhere in your repository; sort of the SVN equivalent
of a hard link.
It is these files that vc-svn does not recognize as svn-controlled right
now.

> resolves my issue, but I can't be sure it doesn't cause problems
> > elsewhere.
>
> Hopefully someone else knows better, but otherwise I suggest you try to
> use this change for a while, testing it with things like
> diff/annotate/younameit.
>
> And then report here if you really think that works better.
>

Well it makes vc-svn recognize the files as svn-controlled, so it
definitely works better :-)
I'll see about putting a fixed version in a private load path, so that if
it breaks something it doesn't affect all users.

[-- Attachment #2: Type: text/html, Size: 2000 bytes --]

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Stefan Kangas]

Tim Van Holder <tim.vanholder@gmail.com> writes:

> On 6 November 2014 16:46, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
[..]
>  > resolves my issue, but I can't be sure it doesn't cause problems
>  > elsewhere.
>
>  Hopefully someone else knows better, but otherwise I suggest you try to
>  use this change for a while, testing it with things like
>  diff/annotate/younameit.
>
>  And then report here if you really think that works better.
>
> Well it makes vc-svn recognize the files as svn-controlled, so it definitely works better :-)
> I'll see about putting a fixed version in a private load path, so that if it breaks something it doesn't affect all users.

That was five years ago.  Are you still using this change?  Does it
work better?  If so, do you still suggest that it should be installed
in the Emacs master branch?

Best regards,
Stefan Kangas

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Tim Van Holder]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

I honestly don't know.
debbugs.gnu.org seems unusable (timeout during TLS handshake), so I can't
check my original report to see exactly what the issue was, or if I still
have local changes.

I can say that I am currently running the 26.1 supplied by Debian, and
vc-svn.el.gz has the same timestamp as all the other .el.gz files, so it
certainly looks like it's the version that ships with Debian.
And that Emacs has no issue recognizing at least some file externals as
version-controlled.


On Thu, 5 Dec 2019 at 12:40, Stefan Kangas <stefan@marxist.se> wrote:

> Tim Van Holder <tim.vanholder@gmail.com> writes:
>
> > On 6 November 2014 16:46, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
> [..]
> >  > resolves my issue, but I can't be sure it doesn't cause problems
> >  > elsewhere.
> >
> >  Hopefully someone else knows better, but otherwise I suggest you try to
> >  use this change for a while, testing it with things like
> >  diff/annotate/younameit.
> >
> >  And then report here if you really think that works better.
> >
> > Well it makes vc-svn recognize the files as svn-controlled, so it
> definitely works better :-)
> > I'll see about putting a fixed version in a private load path, so that
> if it breaks something it doesn't affect all users.
>
> That was five years ago.  Are you still using this change?  Does it
> work better?  If so, do you still suggest that it should be installed
> in the Emacs master branch?
>
> Best regards,
> Stefan Kangas
>

[-- Attachment #2: Type: text/html, Size: 2188 bytes --]

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Stefan Kangas]

Tim Van Holder <tim.vanholder@gmail.com> writes:

> I honestly don't know.
>
> debbugs.gnu.org seems unusable (timeout during TLS handshake), so I
> can't check my original report to see exactly what the issue was, or
> if I still have local changes.

Could you please try again now?  I think there has been some
intermittent issues with debbugs.gnu.org during December, but
hopefully they're resolved.

> I can say that I am currently running the 26.1 supplied by Debian,
> and vc-svn.el.gz has the same timestamp as all the other .el.gz
> files, so it certainly looks like it's the version that ships with
> Debian.
>
> And that Emacs has no issue recognizing at least some file externals
> as version-controlled.

Please check the original issue and report back if you are still
seeing the original issue.

Thanks in advance.

Best regards,
Stefan Kangas

bug#18975: 24.4; vc-svn does not recognize file externals as svn-managed files

[Dmitry Gutov]

Version: 26.1

On 31.12.2019 12:32, Stefan Kangas wrote:
> Please check the original issue and report back if you are still
> seeing the original issue.
> 
> Thanks in advance.

This has been fixed in 2017 in 9b9c93053 using the same kind of proposed 
change.

Thanks all! Closing.