Subversion http protocol through SOCKS 5 server (with authentication)

[Øyvind 'bolt' Hvidsten]

I am trying to access several subversion repositories from behind a 
socks proxy. Client machine runs Debian Linux. I use tsocks to stuff svn 
into the proxy. I can do "tsocks svn co svn://blah.." just fine through 
the proxy, but "tsocks svn co http://blah.."; hangs for a long time and 
then says "Could not read status line: connection was closed by server".


I also tried from an unrestricted network, with ssh -D to localhost to 
set up a quick socks proxy. Same error when using tsocks. Without the 
proxy, the repo works fine.


I can see in wireshark that with tsocks it asks for OPTIONS, as without 
a proxy, gets the OPTIONS back, as without a proxy, and then it just 
sits there, sending no further data until the error apprears and it exits.


In the restricted network, the SOCKS proxy is dante, but as I mentioned, 
the same situation occurs with a simple ssh -D proxy.


I've tested that in both cases, "tsocks wget " works perfectly.
Using http://opkg.googlecode.com/svn/trunk/ for testing, but I've tried 
several others too.


Any ideas?

Re: Subversion http protocol through SOCKS 5 server (with authentication)

[Øyvind 'bolt' Hvidsten]

Testcase:
--
apt-get install tsocks

export TSOCKS_CONF_FILE="$HOME/.tsocks.conf"

cat - >"$HOME/.tsocks.conf" <

tsocks svn co http://opkg.googlecode.com/svn/trunk/
--

On 19/07/13 09:44, Øyvind 'bolt' Hvidsten wrote:

I am trying to access several subversion repositories from behind a
socks proxy. Client machine runs Debian Linux. I use tsocks to stuff svn
into the proxy. I can do "tsocks svn co svn://blah.." just fine through
the proxy, but "tsocks svn co http://blah.."; hangs for a long time and
then says "Could not read status line: connection was closed by server".

I also tried from an unrestricted network, with ssh -D to localhost to
set up a quick socks proxy. Same error when using tsocks. Without the
proxy, the repo works fine.

I can see in wireshark that with tsocks it asks for OPTIONS, as without
a proxy, gets the OPTIONS back, as without a proxy, and then it just
sits there, sending no further data until the error apprears and it exits.

In the restricted network, the SOCKS proxy is dante, but as I mentioned,
the same situation occurs with a simple ssh -D proxy.

I've tested that in both cases, "tsocks wget " works perfectly.
Using http://opkg.googlecode.com/svn/trunk/ for testing, but I've tried
several others too.

Any ideas?

OPTIONS takes exactly one minute

[Hester, Paul]

Certain users are seeing a 1 minute delay on commits. Whilst it isn't certain, 
so far it appears that its only users using WEBDAV authentication. I'm not sure 
what "OPTIONS" does so I guess that's what I want to know so I can track down 
where this delay is occurring.
This is the log of a user with a 1 minute delay. The user not using WEBDAV sees 
the same entries but the OPTIONS is almost instant.

 - - [19/Jul/2013:08:40:29 +0100] "OPTIONS 
/svn/engineering/branches/Libs HTTP/1.1" 401 381 0
 - paul.hester [19/Jul/2013:08:40:29 +0100] "OPTIONS 
/svn/engineering/branches/Libs HTTP/1.1" 200 150 60
 - paul.hester [19/Jul/2013:08:41:29 +0100] "POST 
/svn/engineering/!svn/me HTTP/1.1" 201 - 0


This E-mail and any files transmitted with it ("E-mail") is intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the addressee(s), any disclosure, reproduction, 
copying, distribution or other use of the E-mail is prohibited. If you have 
received this E-mail in error, please delete it and notify the sender 
immediately via our switchboard or return e-mail.
 
Neither the company nor any subsidiary or affiliate or associated company nor 
any individual sending this E-mail accepts any liability in respect of the 
content (including errors and omissions) nor shall this e-mail be deemed to 
enter the company or any subsidiary or affiliate or associated company into a 
contract or to create any legally binding obligations unless expressly agreed 
to in writing under separate cover and timeliness of the E-mail which arise as 
a result of transmission. If verification is required, please request a hard 
copy version from the sender.

Re: Check-out fails with LANG=C

[Vincent Lefevre]

On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> notion of native filesystem encoding on other Unix-like platforms. The
> best we can do is look at the locale settings, specifically, LC_CTYPE.

No, the best you can do is to let the user choose. LC_CTYPE typically
specifies the encoding used by the *terminal*, and this encoding may
change when the user connects by SSH from a terminal with a different
encoding.

> I posit that if the "native encoding" is supposed to be UTF-8, then it
> is an error to use LANG=C at all. Instead, one should use LANG=C.UTF-8.

LANG=C.UTF-8 is completely non-portable for scripts. For instance:

xvii:~> LANG=C.UTF-8 cp
cp: opérande de fichier manquant
Saisissez « cp --help » pour plus d'informations.

xvii:~> LANG=C cp
cp: missing file operand
Try 'cp --help' for more information.

A script that needs to work in some well-defined way, in particular
with English messages (if they need to be parsed), must use the C
(or POSIX) locale. With most tools, this is fine as they don't need
to know how filenames are encoded.

> In a context where, for example, most files were encoded in Big5
> (http://en.wikipedia.org/wiki/Big5) — not a too far-fetched proposition
> — it would be slightly insane, to put it mildly, for Subversion to
> assume it can just write UTF-8 to disk.

Users who want UTF-8 on disk could choose UTF-8 in a config file.
Users who want Big5 on disk could choose Big5 in a config file.
There should also be a way to have ASCII encoding (like what is
done for URL's), for users who want things to work in every context
with the possibly-minor drawback of having some filenames that are
hardly readable with basic tools.

> So indeed, this state of affairs puts the burden of setting up their
> locale correctly on users, but that's simply the way Unix works.

No, according to POSIX, a filename just consists of a sequence of
bytes. How to interpret it is what *you* choose.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

On 2013-07-09 22:50:45 +0200, Stefan Sperling wrote:
> Now, I still wonder why anyone would want to mix and match encodings
> on their filesystems. But this isn't the first time this issue has
> been brought up, so it seems to be important to some of our users.

I don't think that users want to mix encodings on their filesystems.
However different terminals with different encodings may be used
(this may be less and less the case thanks to laptop computers,
though). There's also the question of portable scripts (see my
other post)...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Stefan Sperling]

On Fri, Jul 19, 2013 at 03:22:33PM +0200, Vincent Lefevre wrote:
> On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> > notion of native filesystem encoding on other Unix-like platforms. The
> > best we can do is look at the locale settings, specifically, LC_CTYPE.
> 
> No, the best you can do is to let the user choose. LC_CTYPE typically
> specifies the encoding used by the *terminal*,

No, it determines the character set used by various standard C library
functions that deal with (usually single-byte) characters.

Any behaviour further up the stack is derived and application specific.

Therefore, you are both right and wrong, it depends on the terminal
in use :)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

On 2013-07-19 15:33:55 +0200, Stefan Sperling wrote:
> On Fri, Jul 19, 2013 at 03:22:33PM +0200, Vincent Lefevre wrote:
> > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> > > notion of native filesystem encoding on other Unix-like platforms. The
> > > best we can do is look at the locale settings, specifically, LC_CTYPE.
> > 
> > No, the best you can do is to let the user choose. LC_CTYPE typically
> > specifies the encoding used by the *terminal*,
> 
> No, it determines the character set used by various standard C library
> functions that deal with (usually single-byte) characters.

No, how C library functions behave depend on the current locale,
which is "C" by default. A program needs to call setlocale() to
change the current locale. Obviously it must not do that blindly:
a program may need to deal with different encodings and so on...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Stefan Sperling]

On Fri, Jul 19, 2013 at 03:41:00PM +0200, Vincent Lefevre wrote:
> On 2013-07-19 15:33:55 +0200, Stefan Sperling wrote:
> > On Fri, Jul 19, 2013 at 03:22:33PM +0200, Vincent Lefevre wrote:
> > > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > > Unlike on Windows and Mac OS (the latter at least with HFS+), the is no
> > > > notion of native filesystem encoding on other Unix-like platforms. The
> > > > best we can do is look at the locale settings, specifically, LC_CTYPE.
> > > 
> > > No, the best you can do is to let the user choose. LC_CTYPE typically
> > > specifies the encoding used by the *terminal*,
> > 
> > No, it determines the character set used by various standard C library
> > functions that deal with (usually single-byte) characters.
> 
> No, how C library functions behave depend on the current locale,
> which is "C" by default. A program needs to call setlocale() to
> change the current locale. Obviously it must not do that blindly:
> a program may need to deal with different encodings and so on...

Well, of course. I believe we are saying the same thing.

Re: Check-out fails with LANG=C

[Vincent Lefevre]

On 2013-07-19 15:22:33 +0200, Vincent Lefevre wrote:
> On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > In a context where, for example, most files were encoded in Big5
> > (http://en.wikipedia.org/wiki/Big5) — not a too far-fetched proposition
> > — it would be slightly insane, to put it mildly, for Subversion to
> > assume it can just write UTF-8 to disk.
> 
> Users who want UTF-8 on disk could choose UTF-8 in a config file.
> Users who want Big5 on disk could choose Big5 in a config file.
> There should also be a way to have ASCII encoding (like what is
> done for URL's), for users who want things to work in every context
> with the possibly-minor drawback of having some filenames that are
> hardly readable with basic tools.
[...]

Actually I think that the encoding needs to be stored somewhere in the
working copy. Otherwise even if the user never changes the encoding,
problems may occur, and this is also true with the current behavior.
Indeed it was said in the past that USB keys were supported. So, move
a USB key to a different computer, where the encoding specified by the
environment is different... and see what happens if you try to do an
"svn update"...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Thorsten Schöning]

Guten Tag Vincent Lefevre,
am Freitag, 19. Juli 2013 um 16:32 schrieben Sie:

> Indeed it was said in the past that USB keys were supported. So, move
> a USB key to a different computer, where the encoding specified by the
> environment is different... and see what happens if you try to do an
> "svn update"...

And how do other tools besides svn encode file names on this USB stick
between two different computers with two different OSes? They surely
don't look in the svn working copy. What does cp on my Ubuntu 12.04
and the Windows Explorer on my Windows 7 do if I copy files to FAT
formatted USB stick? How does cp behave on a different, ext4 formatted
USB stick on two different linux distributions? Both don't look into
svn working copies, if cp doesn't, shouldn't svn do the same as cp
whatever it is doing?

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Filename encoding in working copy (was: Check-out fails with LANG=C)

[Vincent Lefevre]

[Cc to the dev@ list]

On 2013-07-19 16:50:49 +0200, Stefan Sperling wrote:
> On Fri, Jul 19, 2013 at 04:32:50PM +0200, Vincent Lefevre wrote:
> > [...]
> > 
> > Actually I think that the encoding needs to be stored somewhere in the
> > working copy. Otherwise even if the user never changes the encoding,
> > problems may occur, and this is also true with the current behavior.
> > Indeed it was said in the past that USB keys were supported. So, move
> > a USB key to a different computer, where the encoding specified by the
> > environment is different... and see what happens if you try to do an
> > "svn update"...
> 
> Simply storing the encoding doesn't really solve anything. Sure, it
> remembers the LC_CTYPE value as the time the working copy was created.
> But then... what?

At least it would work better. And in some cases, one wouldn't notice
any problem. For instance, a repository (and therefore the corresponding
working copies too) may contain mostly filenames with only US-ASCII
characters, and when moving a USB key to another computer, one may be
interested only in a part of the working copy with such filenames.

> We also need to specify some new behaviour that increases user
> convenience for such a new feature to have any value.
> 
> For this, we need answers to questions like:
> How can the client detect whether the stored encoding name matches
> the on-disk encoding? What does it do when they differ? How can users
> re-encode filenames in the working copy when on-disk encoding has changed? 

I don't understand what you mean here. If the chosen encoding for the
filenames is stored in the working copy: The on-disk encoding has been
chosen by Subversion (at checkout time). So, initially it matches the
stored encoding. This normally doesn't change... unless the user has
explicitly chosen to re-encode the filenames globally with some tool.
In such a case, the user also needs to modify the stored encoding, and
Subversion can provide a command for that. Subversion can also provide
a command to re-encode the filenames of a working copy and update the
stored encoding.

The main problem is when a working copy is moved to another machine,
on which the chosen encoding is not supported on the new machine. But
I don't think Subversion can do anything about it. The user needs to
make sure that the chosen encoding is supported on the new machine.
This should be the case for ASCII (+ escaping mechanism) and UTF-8.

> I'm very much interested in enhancements in this area, but at this
> point we don't need to rehash all the problems there are. We need
> to design solutions. This discussion needs a change of direction towards
> being more constructive, or it will die with no results. The discussion
> is also increasingly off-topic for the users@ list.
> 
> In other words, I'm happy to continue this discussion on the dev@ list
> and review your proposed design specs and patches there.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Vincent Lefevre]

On 2013-07-19 17:14:02 +0200, Thorsten Schöning wrote:
> And how do other tools besides svn encode file names on this USB stick
> between two different computers with two different OSes? They surely
> don't look in the svn working copy. What does cp on my Ubuntu 12.04
> and the Windows Explorer on my Windows 7 do if I copy files to FAT
> formatted USB stick? How does cp behave on a different, ext4 formatted
> USB stick on two different linux distributions? Both don't look into
> svn working copies, if cp doesn't, shouldn't svn do the same as cp
> whatever it is doing?

AFAIK, cp is a low-level command that just assumes, like standard
C library functions, that a filename is a sequence of bytes. That
is, it assumes that it is up to the user to re-encode the filenames
if need be. Then, if the bytes need to be interpreted (e.g. for FAT
I assume), it is a driver issue. I suppose that the driver expects
the encoding chosen at mount time (UTF-8 by default?), which it'll
convert to UTF-16 on the physical support.

So, I think that a user who wishes to use FAT under Linux, then
transfer to Windows would do the following:

1. Under Linux, he will do the check out using the UTF-8 encoding,
   so that the driver correctly translates the characters to UTF-16.

2. Whatever locales are used, Subversion would always use UTF-8
   (encoding specified in the working copy) for filenames, so that
   everything is fine on the physical support.

3. The user puts the USB stick on a Windows machine, which recognizes
   UTF-16. I don't think that Subversion needs to cope with the
   chosen encoding under Windows.

For ext4 formatted USB sticks between two Linux machines, the chosen
encoding stored in the working copy would tell Subversion how to
interpret filenames from the working copy.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Check-out fails with LANG=C

[Stefan Sperling]

On Fri, Jul 19, 2013 at 04:32:50PM +0200, Vincent Lefevre wrote:
> On 2013-07-19 15:22:33 +0200, Vincent Lefevre wrote:
> > On 2013-07-09 20:21:33 +0200, Branko Čibej wrote:
> > > In a context where, for example, most files were encoded in Big5
> > > (http://en.wikipedia.org/wiki/Big5) — not a too far-fetched proposition
> > > — it would be slightly insane, to put it mildly, for Subversion to
> > > assume it can just write UTF-8 to disk.
> > 
> > Users who want UTF-8 on disk could choose UTF-8 in a config file.
> > Users who want Big5 on disk could choose Big5 in a config file.
> > There should also be a way to have ASCII encoding (like what is
> > done for URL's), for users who want things to work in every context
> > with the possibly-minor drawback of having some filenames that are
> > hardly readable with basic tools.
> [...]
> 
> Actually I think that the encoding needs to be stored somewhere in the
> working copy. Otherwise even if the user never changes the encoding,
> problems may occur, and this is also true with the current behavior.
> Indeed it was said in the past that USB keys were supported. So, move
> a USB key to a different computer, where the encoding specified by the
> environment is different... and see what happens if you try to do an
> "svn update"...

Simply storing the encoding doesn't really solve anything. Sure, it
remembers the LC_CTYPE value as the time the working copy was created.
But then... what?

We also need to specify some new behaviour that increases user
convenience for such a new feature to have any value.

For this, we need answers to questions like:
How can the client detect whether the stored encoding name matches
the on-disk encoding? What does it do when they differ? How can users
re-encode filenames in the working copy when on-disk encoding has changed? 

I'm very much interested in enhancements in this area, but at this
point we don't need to rehash all the problems there are. We need
to design solutions. This discussion needs a change of direction towards
being more constructive, or it will die with no results. The discussion
is also increasingly off-topic for the users@ list.

In other words, I'm happy to continue this discussion on the dev@ list
and review your proposed design specs and patches there.

Re: When to merge or copy - quick question

[Z W]

Hi Uli

Thanks for responding with your detailed answers.
I would take your suggestion to copy Z branch into Y and then merge Y into
Trunk.

I'm not sure what externals are for.

Another question:
Under what circumstance would one use "svn switch". I understand what it
can do but I still don't see clearly its purpose.

Thanks Uli.

Thanks


On Tue, Jul 16, 2013 at 12:53 AM, Ulrich Eckhardt <
ulrich.eckha...@dominolaser.com> wrote:

> Am 12.07.2013 01:43, schrieb Z W:
>
>  We have a trunk X and a feature branch Y (branched from X)
>>
>
> Your wording is a bit confusing. Let me try to rephrase this: You have a
> project X which has a trunk and a branch Y. The point is that a trunk is
> implied (and typically named "trunk" in the repository).
>
>
>
>  We have another branch Z (totally new code)
>>
>
> If this is new code, i.e. code not related to any existing code, it
> wouldn't be called a branch. The difference is that operations like branch
> and merge are between related code.
>
>
>  and we need to copy branch Z to inside branch Y
>> When we need to merge from branch Y to X, will it work ?
>>
>
> You would copy the new code from Z into the branch Y and later merge the
> trunk with branch Y. Merging changes from branch Y includes things like the
> file copied from Z, so this should work.
>
> To me, Z looks like a separate project. Copying it into a branch of a
> different project is a bit uncommon, so the normal conventions of branching
> and merging don't cover this case. If you want to keep this as separate
> project, too, consider using e.g. externals.
>
>
>
>  When do we decide to svn copy or svn merge for branch Z ?
>>
>
> Normally, creating a branch means making a copy. Later, you only merge,
> both directions from the branch to trunk and from trunk to the branch are
> possible and common. Your case of copying Z into another project isn't
> covered by the typical use cases.
>
> I hope this helped and didn't add to your confusion! ;)
>
> Uli
>
>
>
> 
> **
> Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
> Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
> 
> **
> Visit our website at http://www.dominolaser.com
> 
> **
> Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der
> beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu
> l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder
> anderweitig benutzt werden.
> E-Mails k�nnen durch Dritte gelesen werden und Viren sowie
> nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese
> Folgen nicht verantwortlich.
> 
> **
>
>

Re: When to merge or copy - quick question

[Les Mikesell]

On Fri, Jul 19, 2013 at 1:22 PM, Z W  wrote:
>
> Thanks for responding with your detailed answers.
> I would take your suggestion to copy Z branch into Y and then merge Y into
> Trunk.
>
> I'm not sure what externals are for.

Externals are for where you want a component to appear within one or
more other projects - like library code, and you want the ability to
mange the release/versioning separately.   You put the component in a
separate repository or at a separate project level directory in the
same repository, probably with its own trunk/branches/tags layout, and
use the svn:externals to pull in the revision you want of that
component in each of the other projects that need it.  Typically you
would test/tag the component revisions before using them - and point
the externals to tags, but additional development can proceed
concurrently without affecting the consuming projects until they
adjust their external references to a new tag location.

> Another question:
> Under what circumstance would one use "svn switch". I understand what it can
> do but I still don't see clearly its purpose.

svn switch updates your checked-out workspace to match the revision at
a different url path.  It's the way to move between working on
trunk/branch/tag versions of things.

--
   Les Mikesell
lesmikes...@gmail.com

Re: Migration from Clearcase to SVN

[Andreas Krey]

On Thu, 18 Jul 2013 07:45:52 +, Nico Kadel-Garcia wrote:
...
> * When ready to migrate from the old source control, do a clean dump of the
> old system, and svn import into the new system into a branch, and make a
> locked *tag*. Do not *bother* with the old history.

I strongly disagree with that in that generality. While old history may
be useless to have (and you have it in CC anyway), doing the switch on
a single state is unnecessarily harsh. Instead treat a succession of
states of the 'central' CC branch as a 'vendor branch' and import is
as such into svn. This allows you to continue to run out feature team
branches in CC until all of them have finished while being able to start
new teams on svn beforehand.

While you may not care about *old* history, the history during the
migration is highly helpful. Unless you can afford to do a single shot.

...
> * Under no circumstances maintain parallel work for the same project in
> Subversion and in the old Clearcase, and expect the Subversion history to
> be reconcilable with the parallel Clearcase history

While not trivial this is entirely possible as long as you only want
to sew the two systems together at a single branch (not transferring
the full history, just syncing).

> except by throwing out
> the Subversion repo and starting over from an import.

'Restart from scratch' seems to be a standard svn advice. :-(
(Usually meaning 'do a new checkout'.)

> If I meet one more
> oh-so-clever person who thinks reconciling such things is just a matter of
> a few lines of perl, I will throttle them with their own intestines.

Feel free to come over. I've been doing this for years between CVS and
git with twentyfour lines of shell script and proper procedure (which
is the hard part).

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

vc-svn.el for emacs 21 and single .svn directory

[Karl Berry]

The vc-svn.el file at
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/emacs/vc-svn.el
for svn support in Emacs 21 broke with the change in Subversion that
puts .svn only at the top level of a repository.  Now the
(vc-svn-registered) test for whether a file is in a Subversion
repository always fails, leading Emacs to report that nothing in svn is
"under version control".

I made the following trivial change to have that function merely call
svn status, omitting the efficiency check for .svn/entries, and it has
been working ok.

Not sure if vc-svn.el is maintained here or if anyone besides me on the
planet is still using Emacs 21, but thought I'd pass it along.  If it's
deemed worth submitting as an issue, I'm happy to do that.

Best,
Karl

--- ORIG/vc-svn.el  2013-07-19 16:03:05.740311730 -0700
+++ vc-svn.el   2013-07-19 16:12:16.241234191 -0700
@@ -127,6 +127,5 @@
   "Return true if FILE is registered under Subversion."
-  ;; First, a quick false positive test: is there a `.svn/entries' file?
-  (and (file-exists-p (expand-file-name ".svn/entries"
-(file-name-directory file)))
-   (not (null (vc-svn-run-status file)
+  (not (null (vc-svn-run-status file
+  ;; We used to check for .svn/entries here for efficiency,
+  ;; but now .svn is only at the top level of the repository.
 
Diff finished at Fri Jul 19 16:12:17

Re: Subversion http protocol through SOCKS 5 server (with authentication)

[Øyvind 'bolt' Hvidsten]

For future reference, in case anyone is interested, switching out tsocks 
for the more complicated dante-client makes svn http:// through socks 5 
run perfectly.


On 19/07/13 09:56, Øyvind 'bolt' Hvidsten wrote:

Testcase:
--

apt-get install tsocks

export TSOCKS_CONF_FILE="$HOME/.tsocks.conf"

cat - >"$HOME/.tsocks.conf" <

tsocks svn co http://opkg.googlecode.com/svn/trunk/
--


On 19/07/13 09:44, Øyvind 'bolt' Hvidsten wrote:

I am trying to access several subversion repositories from behind a
socks proxy. Client machine runs Debian Linux. I use tsocks to stuff svn
into the proxy. I can do "tsocks svn co svn://blah.." just fine through
the proxy, but "tsocks svn co http://blah.."; hangs for a long time and
then says "Could not read status line: connection was closed by server".

I also tried from an unrestricted network, with ssh -D to localhost to
set up a quick socks proxy. Same error when using tsocks. Without the
proxy, the repo works fine.

I can see in wireshark that with tsocks it asks for OPTIONS, as without
a proxy, gets the OPTIONS back, as without a proxy, and then it just
sits there, sending no further data until the error apprears and it
exits.

In the restricted network, the SOCKS proxy is dante, but as I mentioned,
the same situation occurs with a simple ssh -D proxy.

I've tested that in both cases, "tsocks wget " works perfectly.
Using http://opkg.googlecode.com/svn/trunk/ for testing, but I've tried
several others too.

Any ideas?