Setting SVN (subversion) http proxy

If you are behind a firewall and have a http proxy on your network you probably will need some extra configuration to be able to download subversion repositories that are outside your network.

SVN does not honor the http_proxy environment variable so you will have to set your subversion http proxy into a configuration file called "servers". This file should be under the subversion local data folder.

On linux, this file is under ~/.subversion.

On windows it should be under %APPDATA%\Subversion

Open the file and add the following lines:

[global]
http-proxy-host=[my.host.name.for.my.proxy]
http-proxy-port=[my.hot.http.port.number]
http-proxy-username=[username]
http-proxy-password=[password]

1) If you do not use username and password, comment them using the #
2) you host name should not contain the http scheme (enter just the host name).

Good luck.

Comments

Post a Comment

Popular posts from this blog

Enterprise Integration Patterns applied in Mule - Dead Letter Channel

Overview This post explains how to use Mule with RabbitMQ AMQP Connector with Dead Letter queues. The Sample code can be easily adapted to other Message Brokers. The Problem We have a Mule application consuming messages from a Message Broker and pushing those messages to a database table. The database server becomes temporally unavailable returning ConnectExceptions. How to save that message that failed to be delivered so it can be reprocessed later when the target system is back? How to retry delivering the same message to the target system before giving up? How to wait between each retry, avoiding overflowing the target system with requests that will most likely fail? Introducing the Dead-letter Channel Integration Pattern This pattern gives the consumer applications an opportunity to reprocess the same message several times. If a final retry also fails, the message is forwarded to an auxiliary queue for further manual intervention. Being selective on the errors we wan...
Read more

Logging in Mule

I don't like wrapping well stablished frameworks to add little to no functionality. It does not sound right. Creating wrappers around log4j is the most common example of this awful practice. It is just a dragging thing that we should all avoid. My point is: if it is simple and it works, just live it alone. After all, the best code you can ever write is the code you did not write! So, most of my Mule applications rely solely on bare Log4j for logging. The below is a collection of some of the best log4j practices I have been using for awhile in my Mulesoft applications. One log file per application Each application logs to its own log files. That is, only the errors thrown by a application are allowed to be written on the main mule console or default log files. Everything else is on the application log file. Therefore, each application have its own appender and logger: ...     <Appenders>         <RollingFile name="file" fileName="${...
Read more

MULE ESB 3.3 - Your java component reading properties from a property file

The problem: I had a mule XML configuration file defining some property files that is loaded by mule container, like this: <context:property-placeholder location="classpath:my-mule-app.properties,classpath:my-mule-app-override.properties" /> and I I had a java component that need to read the value of  a property called jbc.url. That property is on my my-mule-app.properties. Ok, I am pretty sure there are a few other ways to solve this problem but I came up with a very simple solution for that so I want to share (besides that, several ways that I found on the web did not work for me, including using @Value from Spring or using the registry from muleContext). Anyways, here is what worked: This is what I had to add on the flow file configuration file when declaring my java component: <component doc:name="AgeHandler"> <singleton-object class="com.citi.isg.java.components.AgeHandler"> <property value="${jdbc.u...
Read more