[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: Miller, Hugh (hdmi) <HughMiller_at_chevron.com>
Date: Mon, 31 Mar 2008 18:38:46 -0500

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_at_impac.com]
Sent: Monday, March 31, 2008 5:42 PM
To: Miller, Hugh (hdmi); users_at_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_at_chevron.com]
Sent: Monday, March 31, 2008 4:32 PM
To: users_at_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_at_chevron.com

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org

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-01 01:39:07 CEST

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