Using svn as a distrbution deployment mechanism

["Miller, Hugh (hdmi)" <Hu...@chevron.com>]

Subversion seems to offer a nice mechanism for deploying an application
tree. The complete set of files could be distributed from the repository
to remote sites via checkout or export. Subversion also provides
potentially a very nice means for auditing and updating installations.

Would this be an approach to deployment that one could recommend ? Or
are there downsides and issues that would make this approach unviable ?
If  so, could svn be made to work well for purposes like this ?

Many thanks,

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

---------------------------------------------------------------------
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

["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

Re: Using svn as a distrbution deployment mechanism

["Ph. Marek" <ph...@marek.priv.at>]

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: Using svn as a distrbution deployment mechanism

["Miller, Hugh (hdmi)" <Hu...@chevron.com>]

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.

The extra space subversion requires is certainly a concern but might be
acceptable if everything else were very nice. Also there is the remote
possibility that an app might have its own files that clash with the
.svn files, and the possibly less remote chance that svn might
eventually one day fail to recognize a binary and corrupt it.

Perhaps one could envisage an option to subversion adapted to
deployment, avoiding use of .svn files, guaranteed to provide clean bit
for bit repostitory storage and checkout, but providing the control
features like checkin, diff, status, log, update etc. ...


-----Original Message-----
From: Gleason, Todd [mailto:tgleason@impac.com] 
Sent: Monday, March 31, 2008 5:42 PM
To: Miller, Hugh (hdmi); users@subversion.tigris.org
Subject: RE: Using svn as a distrbution deployment mechanism

I think you'd have to wrap it heavily to have a clean experience.
Consider that if the previous version of the app is running or somehow
there are files locked, the update would fail.  A typical installer will
require a reboot and do post-reboot installation tasks then.

You also have to take care of non-copying tasks such as component
registration, invocation of nested installers, etc., no matter what kind
of installation technology.

Also, Subversion leaves you with all the .svn directories and extra
copies of files.  You could use the Subversion working copy as a
separate storage (but then you would total >3 times the application tree
storage), or archive the .svn directories away when your installer isn't
running, but it would be something of a hack.  You could also just get
fresh each time and then wipe out the .svn directories (or do an
equivalent svn export), but you wouldn't want to be running that every
day or anything.

I have to think there are better technologies available for solving this
kind of problem than a version control system.  Given how many web-based
installers we all run that pull down software, I doubt they're all
in-house technologies.

That said, my company's equivalent involves plenty of in-house code.
You may find out that the actual file copying is only one little piece
of your problem though (as I think we did).

-----Original Message-----
From: Miller, Hugh (hdmi) [mailto:HughMiller@chevron.com]
Sent: Monday, March 31, 2008 4:32 PM
To: users@subversion.tigris.org
Subject: Using svn as a distrbution deployment mechanism

Subversion seems to offer a nice mechanism for deploying an application
tree. The complete set of files could be distributed from the repository
to remote sites via checkout or export. Subversion also provides
potentially a very nice means for auditing and updating installations.

Would this be an approach to deployment that one could recommend ? Or
are there downsides and issues that would make this approach unviable ?
If  so, could svn be made to work well for purposes like this ?

Many thanks,

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

---------------------------------------------------------------------
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

RE: Using svn as a distrbution deployment mechanism

["Gleason, Todd" <tg...@impac.com>]

I think you'd have to wrap it heavily to have a clean experience.
Consider that if the previous version of the app is running or somehow
there are files locked, the update would fail.  A typical installer will
require a reboot and do post-reboot installation tasks then.

You also have to take care of non-copying tasks such as component
registration, invocation of nested installers, etc., no matter what kind
of installation technology.

Also, Subversion leaves you with all the .svn directories and extra
copies of files.  You could use the Subversion working copy as a
separate storage (but then you would total >3 times the application tree
storage), or archive the .svn directories away when your installer isn't
running, but it would be something of a hack.  You could also just get
fresh each time and then wipe out the .svn directories (or do an
equivalent svn export), but you wouldn't want to be running that every
day or anything.

I have to think there are better technologies available for solving this
kind of problem than a version control system.  Given how many web-based
installers we all run that pull down software, I doubt they're all
in-house technologies.

That said, my company's equivalent involves plenty of in-house code.
You may find out that the actual file copying is only one little piece
of your problem though (as I think we did).

-----Original Message-----
From: Miller, Hugh (hdmi) [mailto:HughMiller@chevron.com] 
Sent: Monday, March 31, 2008 4:32 PM
To: users@subversion.tigris.org
Subject: Using svn as a distrbution deployment mechanism

Subversion seems to offer a nice mechanism for deploying an application
tree. The complete set of files could be distributed from the repository
to remote sites via checkout or export. Subversion also provides
potentially a very nice means for auditing and updating installations.

Would this be an approach to deployment that one could recommend ? Or
are there downsides and issues that would make this approach unviable ?
If  so, could svn be made to work well for purposes like this ?

Many thanks,

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

---------------------------------------------------------------------
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