That is what we are doing right now except we haven't yet written a script for it.
However, I would really think the diff feature would be useful as you can make sure that on one else had made changes on the server before your changes and didn't deploy them. The server I am working on has change rights for twenty, thirty people. If one person is making changes to pages A, B, C and another person is making changes to B, C, D it's a little hard to see what change you are going to push to production without a feature like this. Come to think of it, it would also be nice to be able to put a lock on the system while one person is editing so that you couldn't have this situation. On Dec 3, 2007 10:48 AM, Aitor Garay-Romero <[EMAIL PROTECTED]> wrote: > An easy solution for this is to have Radiant installed locally on the > customer side. The customer updates the site locally, tests the changes and > when she is happy triggers a script which makes the deployment of the new > database, via rsync, subversion or whatever. So the "master" db is in the > customer side. > > No diff in this case, but it's worth the effort of implementing a complex > diff system? > > /AITOR > > > On Dec 3, 2007 1:16 PM, Matt Hughes <[EMAIL PROTECTED]> wrote: > > > Yeah I thought about using that too. I haven't tried yet to see what > > the diff would look like on the yaml. > > > > What I would really like in the long run, is the ability to diff > > changes between two Radiant installations from the admin interface, > > and then basically apply a patch to the production server from the > > test server. This would be really useful so that users could try out > > a multiple-page/snippet change on the test server; then when they get > > approval or test it out, can just push the change to the production > > server as one transaction. I am going to see how far I can get with > > an extension that could do that. Without this solution, you either > > have: > > > > 1) people making live changes on the production server which could > > result in an inconsistent or buggy state > > 2) changes are too hard to make and require that you involve sys > > admins to move the test db over to the production db > > > > > > > > On Dec 2, 2007 9:34 PM, Daniel Sheppard <[EMAIL PROTECTED]> > > wrote: > > > > First you need to download the snapshot extension (search the mailing > > > > list). This creates a static snapshot of your entire site and put it > > > > in a folder called 'snapshot'. > > > > > > You'd be better off using the import/export extension, completely > > shutting > > > out the admin interface on your live site and only updating your live > > > site through the import/export extension (though I'm not sure how > > > production-ready that extension is). > > > > > > Dan. > > > > > > _______________________________________________ > > > Radiant mailing list > > > Post: [email protected] > > > Search: http://radiantcms.org/mailing-list/search/ > > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > > > > _______________________________________________ > > Radiant mailing list > > Post: [email protected] > > Search: http://radiantcms.org/mailing-list/search/ > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
