unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: vincent.belaiche@gmail.com (Vincent Belaïche)
To: 28245@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Cc: "Vincent Belaïche" <vincent.belaiche@gmail.com>
Subject: bug#28245: 26.0.50; symbolic links not well handled by vc-dir
Date: Sun, 27 Aug 2017 22:52:53 +0200	[thread overview]
Message-ID: <84k21oybq2.fsf@AigleRoyal> (raw)
In-Reply-To: <838ti55bwp.fsf@gnu.org>

My answers bellow...

Le 27/08/2017 à 16:21, Eli Zaretskii a écrit :
>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>> Date: Sat, 26 Aug 2017 23:02:55 +0200
>> Cc: Vincent Belaïche <vincent.belaiche@gmail.com>
>>
>> Hello, I have a project under SVN version control. Under the directory
>> under change control I have a test directory, call it `trunk/test', in
>> which a symbolic link is created to another file, call it
>> `trunk/scr/foo', for the purpose of test. So the symbolic link is
>> `trunk/foo' pointing at `trunk/src/foo'. `trunk/foo' is not under change
>> control, it is created by the test makefile, while `trunk/src/foo' is
>> under change control.
>>
>> Please note that I am under MSW, I have created the symbolic links as
>> native NTFS symbolic links thanks to MSYS2 ln command --- by default
>> this command makes a copy, but it is possible to configure MSYS2 to have
>> native symlinks.
>>
>> OK, `trunk/src/foo' is edited, and when I do `M-x vc-dir', I see in the
>> list of edited files `trunk/src/foo' twice. That is, IMHO, a bug.
>
> vc-dir calls the SVN backend to collect its information, and according
> to my references, SVN doesn't support symlinks on MS-Windows.

You are correct, SVN doesn't support symlinks on MS-Windows. So, it
might well be that nothing is to be done on the Emacs side. But please
read the following...

> Does your port of SVN support symlinks?

FYI, my port is the collabnet one.

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
$ svn --version
svn, version 1.8.13 (r1667537)
   compiled Mar 23 2015, 03:35:53 on x86_64/x86-microsoft-windows5.1.2600

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.8
  - handles 'http' scheme
  - handles 'https' scheme
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

It does not support symlinks to the extent that if there is a symlink in
the repo, then the symlink is not created by a chekcout in the work
area. Instead a plain file containing the link information is
created. However, if I create manually the symlink in place of this
file, then subsequent svn update won't overwrite it.

Now, here, we are not talking about a symlink in the repo, this is a
symlink created locally and which is not under version control.

> What does "svn status -v" show in that repository?

When I do that, I see the original file `foo' only once. Please note
that my bug report is erroneous. Actually, the symlink is
trunk/test/foo, pointing as trunk/src/foo. trunk/src/foo is under change
control, but the directory trunk/test and all its content is not under
change control --- I have not yet imported it. So `svn status -v' done
under trunk shows only, as far as trunk/test and its content are
concerned, this:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
?                                        test
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

My intention was to import trunk/test to the repo with only the files
under trunk/test that aren't created by the test, so the symlinks would
in the end not be under change control, which anyway is impossible
because my SVN client does not support symlinks.

  Vincent.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus






  reply	other threads:[~2017-08-27 20:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-26 21:02 bug#28245: 26.0.50; symbolic links not well handled by vc-dir Vincent Belaïche
2017-08-27 14:21 ` Eli Zaretskii
2017-08-27 20:52   ` Vincent Belaïche [this message]
2017-08-28 17:44     ` Eli Zaretskii
2017-08-28 18:13       ` Glenn Morris
2017-08-28 18:19         ` Eli Zaretskii
2017-08-28 18:33           ` Glenn Morris
2017-08-28 18:38             ` Eli Zaretskii
2017-08-28 22:57               ` Vincent Belaïche
2017-08-28  1:04 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84k21oybq2.fsf@AigleRoyal \
    --to=vincent.belaiche@gmail.com \
    --cc=28245@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).