You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/10/31 00:14:28 UTC
Re: New Tarball with connections fixed.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> Hey someone at collab.net,
>
> Could we post a new tarball including the latest neon, and dav changes
> to use persistent connections properly, and to use the right session
> to get files. It might be useful for people bootstrapping if they could
> actually checkout a copy of subversion :)
I'll do it. Is it safe just to use the latest revision? It has all
the latest fixes, right? (I mean, there are no ra_dav patches
floating out there?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Tarball with connections fixed.
Posted by Philip Martin <ph...@ntlworld.com>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> Now what do I have but in subversion/libsvn_wc/wc.h:534
> #fefine SVN_WC__ENTRY_MODIFY_SCHEDULE 0x0004.
>
> Something seriously weird is going on...
d = 1000000
f = 1000010
A single bit flipped. Bad RAM perhaps?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Tarball with connections fixed.
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Oct 30, 2001 at 06:21:44PM -0600, Ben Collins-Sussman wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > It appears that whatever happened to me didn't affect the repository
> > adversely.
>
> Kevin, I wonder if your working copy is cursed. :-)
>
> Isn't this something like the 3rd time that some "weird" corruption
> has happened in your working copy -- whereby nobody really knows what
> happened, and nobody can reproduce it?
I know what you mean. However, everytime it has happened, I have blown away
my svn tree and checked out a new one. In previous times, I think it might
have been caused by running svn ci --xml-file or svn up --xml-file. This
time however, I haven't done anything out of the ordinary. Like I said,
svn up, ./autogen.sh, ./config.nice, make. Maybe it's just because today is
Halloween :).
Seriously, I can't think of anything that may have caused it. Here is
something interesting though. I just downloaded the tarball from the
downloads page, turned off persistent connections, built it, and used it to
check out the latest version.
Now what do I have but in subversion/libsvn_wc/wc.h:534
#fefine SVN_WC__ENTRY_MODIFY_SCHEDULE 0x0004.
Something seriously weird is going on...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: New Tarball with connections fixed.
Posted by Ben Collins-Sussman <su...@collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> It appears that whatever happened to me didn't affect the repository
> adversely.
Kevin, I wonder if your working copy is cursed. :-)
Isn't this something like the 3rd time that some "weird" corruption
has happened in your working copy -- whereby nobody really knows what
happened, and nobody can reproduce it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proxy support (was Re: New Tarball with connections fixed.)
Posted by Mark Benedetto King <bk...@answerfriend.com>.
On Thu, Nov 01, 2001 at 08:08:55AM +0100, Daniel Stenberg wrote:
> On Wed, 31 Oct 2001, Greg Stein wrote:
>
> > There have been a couple different approaches to handling proxies.
> > Honestly, I'm not really sure what is "best".
> >
> > I know that an environment variable is not preferred, unless there is a
> > hugely widespread, typical usage (like EDITOR).
>
> ... and there just isn't one that widespread.
>
> > We just don't want to use environment variables, if at all possible.
>
> IMO, we could support the ones lynx, wget and others use, but that would be
> an additional feature and should most likely be done purely by the client
> code and we shouldn't depend on it.
Right. lynx and wget both use "http_proxy". Yes, it should be set
by the client code, instead of hard-coded in libsvn_ra_dav, which is
where I put it (I was trying to minimize the scope of the change).
>
> > Second, we need to consider that proxies require (at least) four more
> > pieces of information:
> >
> > 1) proxy host
> > 2) proxy port (default to 80 or whatever)
> > 3) proxy username
> > 4) proxy password
> >
They could, in theory, require other things (kerberos tickets, etc).
> > Somehow, we need to be able to specify any/all of these. Of course, some
> > can go in the .svnrc file, but they could also be needed on a per-project
> > basis.
>
> I could immediately think of situtations when they will be needed on a
> per-project basis:
>
> Like the situation on my current work place. We have the whole internal
> source repository on the internal network, but we use a HTTP proxy to access
> the web. So if I wanna use svn for both inside work sources and remote
> source, I need to set a proxy for for the remote sources only.
>
> More specificly, they actually are on a per-host basis depending on where the
> host is that we get the sources from.
>
> So, either we let the client keep a list with hosts that "don't use the
> default rule", or we add command line flags that says to alter the default.
> Then we can have the default proxy informations in the .svnrc file. If the
> default would be to not use a proxy, we need to be able to specify all these
> four different variables on the command line...
>
I can throw another twist in: when I'm at work, I'm behind a proxy, so I want
one. When I'm not at work, I'm behind a NAT gateway, so I don't. Of course,
I could solve this by switching .svnrc files based on where I am, but it makes
my life easier to simply set an environment variable when I'm at work.
I'm not so happy with command-line approaches; it's a PITA to type a proxy
address on each svn invocation.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proxy support
Posted by Daniel Stenberg <da...@haxx.se>.
On Thu, 1 Nov 2001, Jonathan M. Manning wrote:
> First, the environment variable HTTP_PROXY is very common...
Uh, you mean 'http_proxy' (lowercase), right? Environment variables prefixed
with HTTP_ (uppercase) gets set in CGI environments so you should never use
them otherwise, as using such a program within a CGI script would otherwise
easily become hazaradous.
In the same style, there's usually a 'no_proxy' environment variable as well
that defines a list of hosts that don't need the proxy.
> That sound's like a good strategy. Use http_proxy unless:
> a) a no proxy option is specified on the command line
> b) it's turned off in the per-project config
> c) it's overridden to a new proxy in the per-project config
I could go with this approach.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proxy support
Posted by "Jonathan M. Manning" <jm...@alisa-jon.net>.
Time to throw in my two bits:
First, the environment variable HTTP_PROXY is very common... I find lots of
applications use it as the default proxy settings. You can put it in URL
format too: "protocol://username:password@server:port/". Mine is as simple
as: "http://webdevel:3128/" for a local squid server with no login. Where
users are behind a proxy, chances are, http_proxy is already set for use
with the other applications they use.
If not, a simple 4 parameter configuration as you describe below could
replace or override that environment variable. Or one parameter in the
above format.
As for command line, a wget/lynx style option to ignore the env var might
help.
...from the wget man page:
-Y on/off --proxy=on/off
Turn proxy on or off. The proxy is on by default if the appropriate
environmental variable is defined.
Or, in the rc file:
http_proxy = string
Use the string as HTTP proxy, instead of the one specified in environment.
That sound's like a good strategy. Use http_proxy unless:
a) a no proxy option is specified on the command line
b) it's turned off in the per-project config
c) it's overridden to a new proxy in the per-project config
Second - this is a major need for those of us trapped behind corporate
proxies. It's one of the limiting factors that CVS has. Anonymous (non-SSH
based) access is difficult from behind a proxy.
Glad to finally start contributing,
~Jon
PS - An introduction is probably in order...
I've been on this list for just a few weeks. I'm a heavy CVS user at work,
maintaining all my projects and the company web site (dev and production)
in CVS. I experience daily aggravation with some of the limitations SVN is
aiming to eliminate - moving a file from one directory to another, for
example. Hence, my interest in SVN ;-)
I'm lurking for now, but my involvement will increase dramatically once I
get DSL at my new place - just moved and feeling very internet deprived.
--On Thursday, November 01, 2001 8:08 AM +0100 Daniel Stenberg
<da...@haxx.se> wrote:
> On Wed, 31 Oct 2001, Greg Stein wrote:
>
>> There have been a couple different approaches to handling proxies.
>> Honestly, I'm not really sure what is "best".
>>
>> I know that an environment variable is not preferred, unless there is a
>> hugely widespread, typical usage (like EDITOR).
>
> ... and there just isn't one that widespread.
>
>> We just don't want to use environment variables, if at all possible.
>
> IMO, we could support the ones lynx, wget and others use, but that would
> be an additional feature and should most likely be done purely by the
> client code and we shouldn't depend on it.
>
>> Second, we need to consider that proxies require (at least) four more
>> pieces of information:
>>
>> 1) proxy host
>> 2) proxy port (default to 80 or whatever)
>> 3) proxy username
>> 4) proxy password
>>
>> Somehow, we need to be able to specify any/all of these. Of course, some
>> can go in the .svnrc file, but they could also be needed on a per-project
>> basis.
>
> I could immediately think of situtations when they will be needed on a
> per-project basis:
>
> Like the situation on my current work place. We have the whole internal
> source repository on the internal network, but we use a HTTP proxy to
> access the web. So if I wanna use svn for both inside work sources and
> remote source, I need to set a proxy for for the remote sources only.
>
> More specificly, they actually are on a per-host basis depending on where
> the host is that we get the sources from.
>
> So, either we let the client keep a list with hosts that "don't use the
> default rule", or we add command line flags that says to alter the
> default. Then we can have the default proxy informations in the .svnrc
> file. If the default would be to not use a proxy, we need to be able to
> specify all these four different variables on the command line...
>
> --
> Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
proxy support (was Re: New Tarball with connections fixed.)
Posted by Daniel Stenberg <da...@haxx.se>.
On Wed, 31 Oct 2001, Greg Stein wrote:
> There have been a couple different approaches to handling proxies.
> Honestly, I'm not really sure what is "best".
>
> I know that an environment variable is not preferred, unless there is a
> hugely widespread, typical usage (like EDITOR).
... and there just isn't one that widespread.
> We just don't want to use environment variables, if at all possible.
IMO, we could support the ones lynx, wget and others use, but that would be
an additional feature and should most likely be done purely by the client
code and we shouldn't depend on it.
> Second, we need to consider that proxies require (at least) four more
> pieces of information:
>
> 1) proxy host
> 2) proxy port (default to 80 or whatever)
> 3) proxy username
> 4) proxy password
>
> Somehow, we need to be able to specify any/all of these. Of course, some
> can go in the .svnrc file, but they could also be needed on a per-project
> basis.
I could immediately think of situtations when they will be needed on a
per-project basis:
Like the situation on my current work place. We have the whole internal
source repository on the internal network, but we use a HTTP proxy to access
the web. So if I wanna use svn for both inside work sources and remote
source, I need to set a proxy for for the remote sources only.
More specificly, they actually are on a per-host basis depending on where the
host is that we get the sources from.
So, either we let the client keep a list with hosts that "don't use the
default rule", or we add command line flags that says to alter the default.
Then we can have the default proxy informations in the .svnrc file. If the
default would be to not use a proxy, we need to be able to specify all these
four different variables on the command line...
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Tarball with connections fixed.
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Oct 31, 2001 at 10:58:35AM -0500, Mark Benedetto King wrote:
>...
> It also might make sense to include my http_proxy patch, since that would
> broaden the accessibility of the repository.
There have been a couple different approaches to handling proxies. Honestly,
I'm not really sure what is "best".
I know that an environment variable is not preferred, unless there is a
hugely widespread, typical usage (like EDITOR). We just don't want to use
environment variables, if at all possible.
Second, we need to consider that proxies require (at least) four more pieces
of information:
1) proxy host
2) proxy port (default to 80 or whatever)
3) proxy username
4) proxy password
Somehow, we need to be able to specify any/all of these. Of course, some can
go in the .svnrc file, but they could also be needed on a per-project basis.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Tarball with connections fixed.
Posted by Mark Benedetto King <bk...@answerfriend.com>.
On Wed, Oct 31, 2001 at 10:52:29AM -0500, Kevin Pilch-Bisson wrote:
> On Tue, Oct 30, 2001 at 06:14:28PM -0600, Ben Collins-Sussman wrote:
> > Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> >
> > > Hey someone at collab.net,
> > >
> > > Could we post a new tarball including the latest neon, and dav changes
> > > to use persistent connections properly, and to use the right session
> > > to get files. It might be useful for people bootstrapping if they could
> > > actually checkout a copy of subversion :)
> >
> > I'll do it. Is it safe just to use the latest revision? It has all
> > the latest fixes, right? (I mean, there are no ra_dav patches
> > floating out there?)
>
> Not that I know of...
>
> It appears that whatever happened to me didn't affect the repository adversely.
>
>
It also might make sense to include my http_proxy patch, since that would
broaden the accessibility of the repository.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New Tarball with connections fixed.
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Oct 30, 2001 at 06:14:28PM -0600, Ben Collins-Sussman wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > Hey someone at collab.net,
> >
> > Could we post a new tarball including the latest neon, and dav changes
> > to use persistent connections properly, and to use the right session
> > to get files. It might be useful for people bootstrapping if they could
> > actually checkout a copy of subversion :)
>
> I'll do it. Is it safe just to use the latest revision? It has all
> the latest fixes, right? (I mean, there are no ra_dav patches
> floating out there?)
Not that I know of...
It appears that whatever happened to me didn't affect the repository adversely.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~