Dan, This got long, but here more or less is the process I use each time we need a new server. It's much easier and foolproof if the two machines are the same OS. If so, it's a trivial copy of the entire zope directory. Depending on the products you have installed and how your instalation is set up, this will bring them along as well. In addition, we have a pretty extensive Postgres DB behind our zope, so I've written some shell scripts to dump, transport and load the (postgres) database automagically as well as send along the zope directory. It sounds like you are running two OSs though. In that case, you will need to go through you product list on your production server and reinstall each of those products on your development machine. You might try copying over your Products folder and then restarting zope, and only installing those products that still error out when it starts up. This may work because many products for zope are python only and as such can run unmodified on any OS. Unfortunately this is not always the case and some products have compiled code that has to be recompiled on each platform (database adaptors would be one example). Unfortunately, I don't know of an easy way to know the difference except to examine the product directory and/or the installation instructions for each product. One last caveat with products. I found out the hard way that you can't just copy the products directory if the two zope versions are not identical. The reason is that much of the functionality of zope is implemented as products (pythonscripts, etc). So, if you are copying between versions of zope, you may overrite a newer or older product if you just copy the entire folder. If you are copying a data.fs to a newer version of zope, then it is far better to install individually each product not already on the newer box. I got bit because when we upgraded at one point, I was in a hurry and simply copied over the products folder and overwrote it with a copy of the one from the previous version. This caused some interesting problems which were fixed as soon as I realized what was going on and restored the newer products associated with the newer zope. One final issue that we ran into. If you are using a database adaptor against a database, you will want to make sure you are using the same da on the other OS. At one point we tried running one windows server (demo laptop) via ODBC and a Linux server running a native adaptor (to postgres). Unfortunately, in certain cases, the ODBC adaptor wouldn't accept some of the SQL that the native adaptor was fine with and in other cases the two da's would return slightly different data sets due to the way the adaptors encapsulated the data. It's been almost a year, but I think the biggest issue was that null values with ODBC were returned as an empty string whereas with psycopg they were returned as the python value None. We had the same issue when changing between postgres database adaptors under Linux. The moral of the story we found was it was a lot easier not to change adaptors or platforms too often. We found the easiest thing for us due to the complexity of our app was simply to have our development server be running an identical copy of the code (Zope/Products/DA/DB/OS) that was on the live server(s). This removes one more level of complexity to have to deal with. Then we use ZSyncer to move pieces of zope code from development out to live as they are completed. This has worked admirably well. Our only wish is that the bugs in the versioning code would get fixed (hint, hint). Depending on budgets and such you might take a look at a tool such as vmware. We have had excellent luck with using it for testing purposes given that you have enough memory and horsepower. It would allow you to run an exact virtual copy of your server on your development box while still developing in Windows. I run Windows under Linux on a P3-933 inside a virtual machine under linux with very satisfactory results. We actually demo'ed awhile using an IBM laptop running Windows 2000 Professional with VMWare running an exact duplicate of our Live server (Linux). This worked very well because it allowed our demoer to be in his native environment and run IE while demoing against our app running under Linux. You pay for this with performance. The performance hit seemed to be close to half again as much time in most cases for similiar processor levels. But most of the time, for development having fractionally slower page loads isn't bad. In fact it can force you to write more efficient code (which is a good thing). Anyway, those are some of our experiences. Good luck. -Chris On Monday 13 May 2002 05:29 pm, Dan Shafer wrote:

I'm trying to figure out the best way to take an existing Zope instance on a remote server, which has a *lot* of virtual host stuff and quite a bit of product installed, and replicate it on a local Win2K box both for safety and to give me a local instance to experiment with.

I copied down Data.fs and the related index file to my local Zope instance and fired up the local instance. Of course, I generated a huge number of errors. Not surprising. It became obvious I'd have to either copy down or reinstall locally all the products I've added to the remote Zope instance.

But I'm not at all sure what pieces of the Zope install are essential, which will be automatically generated if not found (indexes?), or, frankly, much of anything else about this process.

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

-- Chris Kratz Systems Analyst/Programmer VistaShare LLC www.vistashare.com