I was thinking of a tool that could be used for different purposes. So if you want to use it as a staging tool, you could call it with some options so that only content/properties are dumped into a single xml file. Versions/Locks could be ignored in this case. This single XML-file could be imported on the live machine in a single transaction. The big advantage is that you are independant of the underlying store. Cheers, Daniel
"Slide Users Mailing List" <[EMAIL PROTECTED]> schrieb am 25.11.04 15:41:15: > > I'm not sure, but I think these two ideas might be of slightly different > magnitudes. I think the original request was how to migrate the minimal > amount of information from a dev/staging instance to the live instance. > Therefore one would not need/want to take all version/meta information > across. It would be a simple "copy from stage to live" sort of function. > I have been thinking about how to implement such a solution as well, but > my solution was not going to store the "live" data in a webdav > repository, just on a filesystem. (I'm not a fan of storing files in a > database, so I use the filesystem store anyway) > > 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] > __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
