I think Daniel's idea was much broader about a full mirror/migration for ALL Webdav content and information. I definately agree that would be a great tool, but I think it might be overkill for the "stage to live" workflow. I guess that is assuming you are moving items piece by piece as they are approved.
Tim
Daniel Florey wrote on 25/11/04 03:03 AM:
Yes, please!! This is what I had in mind for a longer time, but never managed to start working on it: A WebDAV-client-tool that determines the server capabilities by doing some OPTIONS request and retrieves the content by doing the appropriate WebDAV-requests afterwards. This would have the big advantage that it works with different WebDAV-based repositories and works if different Slide instances use different storage configurations. It might be a bit tricky to retrieve not only the content but also properties, locks, acl and versioning information, but it finally would be the most elegant solution. If we find a good XML representation for content/properties etc. we could use this for data import as well. The xml-format could consist of nested elements representing each resource. This would enable to "dump" the repository located under a given path and import it to a different location. Optional flags could be used to ignore locks/acl/versioning information. Just a dream... or is someone interested in implementing this? As stated before I had this on my personal roadmap for a while but am very busy at the moment and can hardly find the time to do it.
Cheers, Daniel
"Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 24.11.04 23:04:34:
It sounds like writing a client tool to migrate content from one Slide server to another one might be a good option. This should be fairly simple to write using the Webdav client library. Another option that I originally had in mind is to simply perform a database dump on the staging server and upload this to production. Of course, this would preserve the entire version history, which we most likely won't care about on our production server, so a separate tool might be more appropriate.
-Mirko
On Wed, 2004-11-24 at 13:58, Richard Emberson wrote:
I must preface my remarks by stating that our Slide deployment will use a database for storage.
Consider Slide namespaces. From what I've heard and based upon the mailing list traffic, multi Slide namespace installations do not occur very often. Lets say that such installations work just fine, - each namespace could use a different database - one would need some external Slide/webdav tool/script to promote (copy) directories from dev namespace to test namespace to production namespace. Since one has to create and use such a promotion tool, its not clear that having a single Slide with three namespaces buys one anything over having three distinct Slides each with their own DB. I am assuming that to promote a directory involves getting it (the whole directory hierarchy) into the (client) tool from one Slide server and then putting into a second Slide server. This is true even if one has the three Slide databases on the same database server; one must extract the directory from one db and insert it into another.
Our dev Slide server will be version controlled while the test and production need only have non-versionable copies.
Mirko Froehlich wrote:
Our current staging environment really serves a different purpose. Our test, staging, and production servers correspond to phases in our software development cycle and are strictly separated. We definitely wouldn't want to use the production Slide server for development or test purposes, so those at the minimum would need to be separate servers. However, my example of publishing web content from staging to production uses a different concept of staging than we currently have, so it may not be an ideal example. I suppose for this scenario the content could very well live in two different folders on the production Slide server, with a simple publishing process that copies or moves content from the staging to the production server. I guess in the end this really depends on the workflows we need. For example, for content updates on the live site this approach would probably work well. But lets say we develop a new major version of the application with significant changes to our web content management framework and corresponding new content in the repository. When this goes live, we would need to publish the content from the staging Slide server to the production server.
I know this is somewhat hypothetical at this point. I'm just trying to get a feel for how people use Slide. Yours is definitely a viable option.
-Mirko
On Wed, 2004-11-24 at 12:58, Richard Emberson wrote:
For my information, why would you not have top-level directories: dev, staging, and production; all within the same Slide server?
Richard
Mirko Froehlich wrote:
Those of you who are using Slide in a production environment, what kind of publishing workflow have you put in place?
We will likely end up using Slide for various aspects of our application. Initially, it will mostly serve as a repository for user-specific application data. In this scenario, the user data would only live on the production server and there would not have to be a publishing process that moves data from staging to production. However, there's a good chance that we may end up using Slide for web publishing as well, in which case we would probably want to be able to manage content on the staging server and push it to production as part of a publishing workflow.
I suppose this could be as simple as performing a database dump on staging and loading it on production. We would probably set up multiple db stores, which would allow us to publish the part of the repository that is used for web publishing, but not the part of the repository that contains the users' application data.
Anyway, I would be interested in hearing about your experiences and best practices that you have determined for these kinds of scenarios.
-Mirko
________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
