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

Re: software distribution with subversion

From: Branko ÄŒibej <brane_at_wandisco.com>
Date: Fri, 01 Feb 2013 00:37:41 +0100

I expect you've considered this option, but just to add it to the list:
Why not use a package manager like apt or yum, or a distributed
configuration manager such as puppet, to manage your servers?

While Subversion can be used as a substitute, it's not really suited for
this kind of application -- especially if the software has to be
customized for each node.

-- Brane

On 31.01.2013 23:10, Jason Keltz wrote:
> Hi.
>
> I am faced with a problem where I need to distribute a directory
> containing about 60 GB worth of software on a Linux file server to
> about 100 systems. The software must be localized on those systems
> and not shared out over NFS. On a regular basis, software may be
> added or removed from the directory, and all the clients should update
> accordingly in the evening. During the update period, some client
> systems may be off.
>
> I think that Subversion would be a reasonable way to solve this
> problem which isn't quite the type of problem that rsync is intended
> to handle (because of the number of machines). However, for a variety
> of reasons, I don't want to run subversion on the actual file server.
> Instead, nightly, I'd like to rsync changes in the contents of the
> software directory on the file server to a software distribution
> server which would run its own svnserve. The clients would then
> connect up to the server nightly, and update themselves accordingly.
> Because of the versioning, if a client misses an update, it would be
> updated the next time around, even if its been off for a while.
>
> The inital update between the file server and the software update
> server would require rsyncing the whole 60 GB of software to a
> "working directory", after which, to make subversion see this as a
> "working directory", I would have to commit the entire directory, then
> check it back out. This process seems like a bit of a waste, but it's
> a one time process, and I don't really see any way around it. In the
> future, I would like to be able to rsync changes between the file
> server and the working directory on the software distribution server,
> which would including using --delete to ensure that software deleted
> from the file server is also deleted from the subversion working
> idrectory, and including the excluding of the .svn directory from the
> working copy. However, after the rsync happens, I now need to run a
> command that would update the repository with the state of the working
> directory. However, it's not exactly clear how this would work?
> Running an "svn update" isn't going to delete directories from the
> repository that were deleted from the working directory. I believe
> you need to use "svn delete" for this?
>
> Any ideas that anyone might be able to offer?
>
> I'm not on the list, so please ensure that you CC: me in any response.
>
> Thanks for your help!
>
> Jason.

-- 
Branko ÄŒibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-02-01 00:38:17 CET

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

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