On Friday 15 November 2002 05:37 am, Stephen Pair wrote:

> My questions are this...can DVS cope with situations where changes
> need to be very carefully ordered?  Or should I just continue using
> a change set for the preload and perhaps use DVS for the other.

DVS itself doesn't handle this well. It does have a facility for 
supplying preamble and postscript texts via a PackageInfo subclass.

What I'd do is factor out the various CS bits and put them into a SAR 
along with the one (or more) .st files from DVS that you're working 
with. You can then have the install/preamble do the proper ordering 
and loading.

> And, how well do DVS and SAR work together?  Specifically, can I
> bundle a preload change set with a DVS package and have it wrapped
> neatly into a SAR and make the change set load prior to the DVS
> package?

They work together rather well (that's how I distribute Connectors). 
However, the automatic building process is a bit in flux at this 
point. There is code in the DVS distro on SM (or is it in the 
SARBuilder?) that builds SARs from a DVS package (possibly with other 
added change sets). BUT... the code doesn't actually compress the 
members (this was an oversight on my part, and I'm working with Avi 
on a re-factored version that works with his refactored DVS). You can 
re-compress easily, though, by doing this:

* open the generated uncompressed SAR in the Archive Viewer.
* window menu, choose "inspect archive".
* in the inspector, evaluate:
self members do: [ :m | m desiredCompression: ZipArchive deflated ].
* then save the archive under another name

What happens when you ask for this DVS->SAR generation is this:

install/postscript comes from your PackageInfo subclass's 
"postscriptText"

install/preamble comes from your PackageInfo subclass's "preludeText",
and then has CS-loading code appended like this:

self ifNotNil: [
	self fileInMemberNamed: 'MyFirstCS.cs'.
].

etc.


-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE