Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Envelope-To: users@subversion.apache.org
Envelope-To: jas@cse.yorku.ca
Date: Fri, 1 Feb 2013 09:35:24 +0100
From: =?iso-8859-1?Q?Thorsten_Sch=F6ning?= <tschoening@am-soft.de>
Organization: AM-SoFT IT-Systeme
Message-ID: <1322500150.20130201093524@am-soft.de>
To: users@subversion.apache.org
CC: Jason Keltz <jas@cse.yorku.ca>
Subject: Re: software distribution with subversion
In-Reply-To: <510AEBD6.5060508@cse.yorku.ca>
References: <510AEBD6.5060508@cse.yorku.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Guten Tag Jason Keltz,
am Donnerstag, 31. Januar 2013 um 23:10 schrieben Sie:

> Any ideas that anyone might be able to offer?

As it seems most answers vote against using Subversion and use rsync
or some alternative instead, I would like to add some ideas which vote
for Subversion because I use a similar approach like yours with one of
our products some of my customers. It's not about 60 GB of data,
though, only around 75 MB per client, but each client needs some
little customizations, for example. In my environment my customers use
SSH to establish a tunnel to access a special svnserve instance only
serving binary data which can directly be used without installation or
else. It's just a simple directory structure which is in most cases
saved on a file server of a customer and used by it's own clients from
there. I found this to work quite well as it's an easy and flexible
setup. Some of my customers use this access to get the data and build
customized MSI installation packets for Windows on their own.

1. rsync files to deployment server

Besides the reasons not running svnserve on the file server itself,
why don't you seem to consider running the working copy for your trunk
or whatever will be the source for your deployment server on the file
server? This would need more space on the file server, of course, but
it would save you the rsync to the deployment server and the working
copy on the deployment server. How are changes to the directory
structure on the file server applied at all? If it is from users, they
could already use Subversion clients to apply those changes and could
deal with moves, renames, deletes etc. in the proper Subversion way
which would provide full tracking and history of the changes.

2. repo size

Depending on your data, Subversions representation sharing of content
could save you a lot of repo space. While the clients still had to
deal with pristine copies etc., the needed space for your deployment
server may be a lot less than your mentioned 60 GB. Another good thing
on representation sharing is that it works on a per repo basis, not
e.g. per directory, which means that even if you branch a lot of
clients for any reason and each client needs to get updated binaries
the total amount of space needed won't scale with the number of
clients branched, but only with the different binary changes
committed, which could be a lot less in an environment were all
clients need to have the same binaries.

3. customizations for some clients

You descriptions reads like each and every client has exactly the same
data set to fetch. What's the chance for exceptions and that some
clients need special binaries, configuration files or whatever for
some reasons? With a "simple" rsync approach this would really
complicate your setup as you would need another directory structure
with full data or need to symlink some parts of your directory
structure or whatever. Using subversion you could easily, fast and
efficient branch the clients which need customizations and if you use
working copies on the file server your users could easily apply those
customizations and see which customizations are made. This would make
your maintenance life much easier than generating a diff between do
directory structures which are used as a rsync basis.

4. updates by revision

Depending on the size of your changes, I agree that using Subversion
for updates will be much more efficient than running rsync and letting
it calculate the needed changes. It's not a matter of if rsync will be
slower but only how slow it will perform and if this would be a real
problem in environment or not. But from my point of view it a simple
space vs. processing time if you look at Subversion vs. rsync.

5. pristine space needed on clients

You didn't seem to mention what kind of clients you need to update.
Depending on their kind the doubled space for pristine copies may not
even be a problem at all.

6. Server access and security

Did you already think of security, is there any need to secure clients
against each other at all? Using rsync and especially customizatioins
you would maybe need to create a lot of users and or groups and use
security on the file system and OS level. Subversion provides it's own
configuration which may even be versioned itself for documentations
purposes etc.

Mit freundlichen Gr=FC=DFen,

Thorsten Sch=F6ning

--=20
Thorsten Sch=F6ning       E-Mail:Thorsten.Schoening@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=E4ftsf=FChrer: Andreas Muchow