One of my biggest painpoints with Radiant is figuring out what is
different on my local copy and my test server’s copy and keeping them
in sync. I think I just figured out a half-decent way to do it…
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’.
Install the extension in both Radiant installations.
Create snapshots of each (it outputs the whole site to
${RAILS_ROOT}/snapshot) and use ‘diff’ to compare them.
It’s a little tedious but I’m sure someone who is better at Capistrano
could probably do this in a script.
A caveat that I am seeing is that since you are diffing over the
generated page, if you made any changes to your layouts, those changes
are repeated on every single page.
It might be better if I could dump the layouts and pages seperately
and then do a diff on them. I’ve tried just doing a diff of the
database dumps and they are horrible.
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.
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:
- people making live changes on the production server which could
result in an inconsistent or buggy state
- changes are too hard to make and require that you involve sys
admins to move the test db over to the production db
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
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, at 11:00 AM, Matt H. wrote:
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.
I can certainly see the benefit of what your are proposing, but don’t
see it as something that should be developed by the core team as it
doesn’t fall within the realm of things that are important for a CMS
for small teams (6-8 people). Consider developing an extension. There
may be others here on the list who would be interested in lending a
hand.
–
John L.
http://wiseheartdesign.com
