[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Light weight client question.

From: Ross Mark <rossm_at_controllingedge.com.au>
Date: 2003-06-28 05:07:56 CEST

I think this question will be like many others and the answer is not
till after version 1 but I was wondering if following might be easily
achievable now. I'm also willing to code it my self but want to get some
idea of the scope of the problem.

I'm after a light weight version of the svn+http client. This client
would only allow checkout's and updates (switch too as it is just a type
of update). There is absolutely no need to do a checkin. Given this case
the problems that normally arise from having a working copy and the
original file should not be an issue since the original is only needed
for determining the delta on a checkin.

If I explain my environment you will better understand my reasons for
such a light weight client.

I work on embedded linux systems that have only a limited amount of disk
space (16M flash). In most cases our devices connect to the internet via
GPRS modems however they can be placed on an existing twisted pair
network for access, though normally through a firewall. We use SOAP over
http as our normal communication protocol and our devices always
initiate connections to the servers so firewalls aren't an issue. To
upgrade these devices in the field we use rsync. It is fairly efficient
and works well, except when the device is behind a firewall. Most
corporation would block rsync along with ssh and rsh. I've tried
searching for rsync over http but no luck yet.

Subversion appears to be the perfect solution for upgrades as it already
works over http and hence the firewall issues disappear. Plus with the
way it keeps track of versions it would send only the required data to
get the system upgraded. From the version number we could easily query
what version a system is using. Lots of pluses in every direction.

The big issue currently with subversion is the space requirements as we
just don't have the ability to duplicate the file in the working copy
and the text base. I know this issue has been raised many times.

Just to let you know I currently store our embedded system images under
subversion and just configure rsync not to hand out the .svn
directories. By using a shell wrapper around svn I use svn properties to
store the currently unrecorded information like symlinks, device nodes,
owner and groups plus permissions. Nothing gets missed.

Any feed back or thoughts on such a client would be appreciated.

Guys keep up the excellent work. I have installed CVS servers at a
number of companies over the years and currently subversion addresses
all the problems I had with CVS. It still needs a little more work on
the svn:externals side of things but the current system is very usable.

Cheers

Ross Mark
One very happy svn user.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 28 05:08:49 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.