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

Re: Using svn as a distrbution deployment mechanism

From: Ph. Marek <philipp_at_marek.priv.at>
Date: Thu, 3 Apr 2008 08:49:17 +0000 (UTC)

Hello Hugh!

Miller, Hugh (hdmi <HughMiller <at> chevron.com> writes:
> We too have our in-house methods for deployment but they lack the kind
> of control version control systems have. They really come down to more
> or less sophisticated copy mechanisms.
>
> In our case (linux only), deployment/update is controlled by local
> support folks so collision with a running app is at least a "managed"
> risk ;). Also the model for deployment is basically <copy files>+<edit
> site config file>+<run make site>, controlled locally. Thus there is a
> standard component in the file set (for a given version, the same
> everywhere, no local changes) and a local component, customized to the
> particular location. Only the standard invariant part would be under
> central version control. It looks to me like a file set that should in
> principle be amenable to handling by version control.
Basing a distribution on some static data, some specific informations and a
Makefile where everything is versioned is what I'd like to do as soon as I get
the time for that.

That's exactly the use-case where FSVS (http://freshmeat.net/projects/fsvs)
might fit your bill:
- Uses a subversion repository
- Really fast, even for several hundred thousand inodes on cold caches
- No .svn-directories
- Keeps mtime, owner, group and mode
- and some more features ...

I'd ask you to try it; maybe it's what you're looking for.

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-03 10:55:28 CEST

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.