You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Ph. Marek" <ph...@marek.priv.at> on 2008/04/03 08:49:17 UTC

Re: Using svn as a distrbution deployment mechanism

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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Re: Using svn as a distrbution deployment mechanism

Posted by "Miller, Hugh" <Hu...@chevron.com>.
Hi Phil,

Many thanks for the information.

The features you mention do address desires, and concerns, which we are
discussing in considering svn.

I'm starting to look at FSVS now.

Best,
-
>Hugh Miller
>e-mail:	HughMiller@chevron.com


-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Ph. Marek
Sent: Thursday, April 03, 2008 3:49 AM
To: users@subversion.tigris.org
Subject: Re: Using svn as a distrbution deployment mechanism

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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org