Re: [Radiant] Wacky version control idea for content
On 5 Oct 2008, at 00:30, Jay Levitt wrote: Just a thought I had in the shower: Most attempts at CMS version control end up reinventing large parts of subversion/git/etc. inside the database. Instead... Why not use something like FuseFS to implement a filesystem that maps the Radiant asset tree to paths like /dev/radiant/pages/ home_page? Then use the version control system of your choice. That's not wacky, it's a great idea! The file_system extension was designed for this purpose. Check it out here: http://github.com/nelstrom/radiant-file-system-extension/tree/master It was originally designed by Sean Cribbs, but I am responsible for maintaining it now. If you choose to try it out, I would recommend taking a backup of your database first, as the behaviour is not entirely predictable. In particular, I would recommend save/load all models at all times. e.g. rake file_system:save rake file_system:load DON'T do this: rake file_system:save:layouts rake file_system:load Which would wipe pages and snippets from your database, preserving only layouts. This is a bug that I plan on fixing asap. At the moment, the extension doesn't play very well with subversion, so be aware of this if you choose to add the design directory to a svn repository. The reason has to do with subversion placing a hidden .svn directory inside every directory that is under version control. Any scm system that doesn't do this (such as git) should play fine with the file_system extension. I plan on addressing this issue, but haven't decided on the best strategy yet. Cheers, Drew [1]: http://ext.radiantcms.org/extensions/ ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Wacky version control idea for content
Andrew Neil wrote: On 5 Oct 2008, at 00:30, Jay Levitt wrote: Just a thought I had in the shower: Most attempts at CMS version control end up reinventing large parts of subversion/git/etc. inside the database. Instead... Why not use something like FuseFS to implement a filesystem that maps the Radiant asset tree to paths like /dev/radiant/pages/home_page? Then use the version control system of your choice. That's not wacky, it's a great idea! The file_system extension was designed for this purpose. Check it out here: http://github.com/nelstrom/radiant-file-system-extension/tree/master Ah hah! I saw that yesterday, but (so far, at least) it looks like it's targeted at explicit save/loads. Are you thinking of taking it in the live filesystem direction? That would be very cool. I did a little more Googling on FuseFS, and it seems that the RubyForge project is stagnant, but that a few people have got some version of it working on some OS's sometimes... http://www.datanoise.com/articles/2007/3/9/macfuse-and-ruby-fusefs-extension I don't have an immediate need for version-control myself (other than It Would Be Cool), but, well, it WOULD be cool. Jay ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Wacky version control idea for content
At the moment, the extension doesn't play very well with subversion, so be aware of this if you choose to add the design directory to a svn repository. The reason has to do with subversion placing a hidden .svn directory inside every directory that is under version control. Any scm system that doesn't do this (such as git) should play fine with the file_system extension. I plan on addressing this issue, but haven't decided on the best strategy yet. Drew, Andrew vonderLuft and I are using this with SVN and haven't run into that problem. Is this a problem only with pages? Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Regarding github's SnS extensions -- safe to use?
Tim Gossett wrote: I haven't updated the GitHub repo in a while because I'm not sure how to have a slave git repo sync up with a master SVN repo. Anyone? It looks like you *should* just be able to do this in your local repository: git svn rebase # pull trunk changes from svn git svn dcommit # push git changes to svn git push# push to remote repository (github) But there are a zillion caveats in the docs, so that may or may not work so well in practice with github. It sounds like you're better off keeping a local repository that's used for nothing but the git-svn syncing: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html (See the Basic Examples section, which is anything but basic) Jay Levitt ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Regarding github's SnS extensions -- safe to use?
It looks like you *should* just be able to do this in your local repository: git svn rebase # pull trunk changes from svn git svn dcommit # push git changes to svn git push# push to remote repository (github) But there are a zillion caveats in the docs, so that may or may not work so well in practice with github. It sounds like you're better off keeping a local repository that's used for nothing but the git-svn syncing: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html (See the Basic Examples section, which is anything but basic) Jay Levitt Back in the spring when we were just trying out git and meanwhile maintaining the SVN repo, things got a little tedious and unpredictable to keep the SVN up-to-date, especially with changes that weren't done to my local git-svn repo. It's better to keep one or the other, if possible. Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Wacky version control idea for content
On 5 Oct 2008, at 12:32, Jay Levitt wrote: The file_system extension was designed for this purpose. Check it out here: http://github.com/nelstrom/radiant-file-system-extension/tree/master Ah hah! I saw that yesterday, but (so far, at least) it looks like it's targeted at explicit save/loads. Are you thinking of taking it in the live filesystem direction? I don't plan on taking it in that direction, but if it is a useful starting point, then you could always fork the file_system extension. Sorry I mistook the meaning of your original email. I was not familiar with FuseFS, or what it aims to achieve. It looks interesting. Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Wacky version control idea for content
On 5 Oct 2008, at 14:59, Sean Cribbs wrote: At the moment, the extension doesn't play very well with subversion, so be aware of this if you choose to add the design directory to a svn repository. The reason has to do with subversion placing a hidden .svn directory inside every directory that is under version control. Any scm system that doesn't do this (such as git) should play fine with the file_system extension. I plan on addressing this issue, but haven't decided on the best strategy yet. Drew, Andrew vonderLuft and I are using this with SVN and haven't run into that problem. Is this a problem only with pages? Yes, pages only. I also have a site which uses the file_system extension with svn, and most of the time it works just fine. But there is one particular use-case which can cause problems. It is a little difficult to describe, but I shall try and do so briefly here. Assuming we start with a Radiant site which is stored in the database, but not yet on the filesystem, and the project is under svn control. First, we run: rake file_system:save which saves all layouts, snippets and pages to the file system, within a /design directory. Now suppose we run: svn add design svn commit -m Captured site on file_system Now the contents of the /design directory is under version control. A side effect of this, is that every subdirectory beneath design contains a hidden .svn directory. Suppose you make further changes to the site through the Radiant admin, then, to keep things in sync, you run `rake file_system:save` again. [Here is where it gets messy:] If your changes included the deletion of a page, then the file_system:save action should delete the directory on your file system corresponding to the page that was deleted. In doing so, it will delete the hidden .svn directory which subversion was using to track the contents of that directory. Subversion complains when a directory goes missing which it thinks should be there. When I found myself in this position, I was unable to commit my latest revision. I think I got around the problem in the end, by doing `svn up` to restore the directory that had been deleted by running `rake file_system:save`, and then I deleted that directory by hand, using the `svn rm /design/pages/page-to-be-deleted` command. (I am no expert with svn, so perhaps I'm doing it wrong?) To make the file_system:save action play well with subversion, I am thinking it would probably be necessary to use `svn rm` within the rake task, rather than calling ruby's `FileUtils.rm()` method, but only if the directory contains a .svn/ directory. I've been scratching my head over this for a while, and would really appreciate any thoughts on the matter. Cheers, Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Wacky version control idea for content
Ah, that makes sense. Yeah, we've been relying on import_export for
capturing pages in the SCM. The main impetus for the other stuff being
in the SVN is that it's primarily design-time - snippets and layouts
(and in our case, templates as well), hence the design directory.
However, I also often forget to use `svn rm`, so I set up a sake task to
delete missing directories for me. It looks like this:
desc 'Delete files from the SVN working copy that are missing'
task 'delete_missing_files' do
`svn status`.split(/\n/).each do |line|
system(svn delete --force #{$1.gsub( , \\ )}) if line =~
/^!\s+(.*)$/
end
end
Hope that helps!
Sean
Andrew Neil wrote:
On 5 Oct 2008, at 14:59, Sean Cribbs wrote:
At the moment, the extension doesn't play very well with subversion,
so be aware of this if you choose to add the design directory to a
svn repository. The reason has to do with subversion placing a
hidden .svn directory inside every directory that is under version
control. Any scm system that doesn't do this (such as git) should
play fine with the file_system extension. I plan on addressing this
issue, but haven't decided on the best strategy yet.
Drew,
Andrew vonderLuft and I are using this with SVN and haven't run into
that problem. Is this a problem only with pages?
Yes, pages only. I also have a site which uses the file_system
extension with svn, and most of the time it works just fine. But there
is one particular use-case which can cause problems. It is a little
difficult to describe, but I shall try and do so briefly here.
Assuming we start with a Radiant site which is stored in the database,
but not yet on the filesystem, and the project is under svn control.
First, we run:
rake file_system:save
which saves all layouts, snippets and pages to the file system, within
a /design directory. Now suppose we run:
svn add design
svn commit -m Captured site on file_system
Now the contents of the /design directory is under version control. A
side effect of this, is that every subdirectory beneath design
contains a hidden .svn directory.
Suppose you make further changes to the site through the Radiant
admin, then, to keep things in sync, you run `rake file_system:save`
again.
[Here is where it gets messy:]
If your changes included the deletion of a page, then the
file_system:save action should delete the directory on your file
system corresponding to the page that was deleted. In doing so, it
will delete the hidden .svn directory which subversion was using to
track the contents of that directory.
Subversion complains when a directory goes missing which it thinks
should be there. When I found myself in this position, I was unable to
commit my latest revision. I think I got around the problem in the
end, by doing `svn up` to restore the directory that had been deleted
by running `rake file_system:save`, and then I deleted that directory
by hand, using the `svn rm /design/pages/page-to-be-deleted` command.
(I am no expert with svn, so perhaps I'm doing it wrong?)
To make the file_system:save action play well with subversion, I am
thinking it would probably be necessary to use `svn rm` within the
rake task, rather than calling ruby's `FileUtils.rm()` method, but
only if the directory contains a .svn/ directory.
I've been scratching my head over this for a while, and would really
appreciate any thoughts on the matter.
Cheers,
Drew
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] New wiki article: removing scaffolding from the Link Roll
On 3 Oct 2008, at 00:17, John W. Long wrote: On Oct 2, 2008, at 6:52 PM, Andrew Neil wrote: I've written a new article for the wiki, which follows on from the original Creating Radiant Extensions[1] tutorial. It demonstrates how to remove the scaffolding from your extension, and style it so that it looks more like it belongs in Radiant. Find it here: http://wiki.radiantcms.org/Radiant_extensions_without_a_scaffold I would be very pleased if anyone could follow it though, and let me know if everything makes sense. It is a wiki, so do please fix any typos or factual errors. I was originally planning to merge this directly into the Creating Radiant Extensions article. When I first read that article, it recommended using scaffold :link in the LinksController, but since Radiant moved onto Rails 2 this method hasn't worked. There is a section now in the article called Hacking a Scaffolded Controller and Views, which I hadn't seen before. I considered deleting that section, and replacing it with the article above, but I wondered if it made the article just too long. Great stuff here Andrew. Why don't you merge this with the original tutorial (delete the Hacking section), but make your article a Part 2 on a separate page. That way it will complete the original tutorial. Thanks John. I've split the original article in two, as you suggested: http://wiki.radiantcms.org/Creating_Radiant_Extensions http://wiki.radiantcms.org/Creating_Radiant_Extensions_B I put the controller, view and route stuff into the first part of the article, pushed the Creating custom tags stuff into the second part, and finished off with the CSS and images to make the admin area look more like part of Radiant. I've removed Bill's section on hacking a scaffold. I still need to update the screenshots, but I'll get round to that later. Cheers, Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extension Development in Git
It strikes me that this would be best handled in the extension registry so that each author could handle extension releases as he/she pleases. So script/extension could grab whatever is marked as the latest by default or take an argument for a particular release (which would be set by the author in the registry). On Oct 5, 2008, at 3:36 PM, Marty Haught wrote: I've been wondering how best to maintain stable and unstable branches of an extension in Git. Traditionally you'd keep the master as 'trunk' which would be considered unstable and you'd tag official releases. We could use this approach but I'm wondering how best this works with the new radiant extension install script. Would it be better to get master as the current official release and make a branch, say edge, that is the development portion? Cheers, Marty ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] file_system extension (was Wacky version control idea for content)
On Oct 5, 2008, at 1:46 PM, Andrew Neil wrote: On 5 Oct 2008, at 14:59, Sean Cribbs wrote: At the moment, the extension doesn't play very well with subversion, so be aware of this if you choose to add the design directory to a svn repository. The reason has to do with subversion placing a hidden .svn directory inside every directory that is under version control. Any scm system that doesn't do this (such as git) should play fine with the file_system extension. I plan on addressing this issue, but haven't decided on the best strategy yet. Drew, Andrew vonderLuft and I are using this with SVN and haven't run into that problem. Is this a problem only with pages? Yes, pages only. I also have a site which uses the file_system extension with svn, and most of the time it works just fine. But there is one particular use-case which can cause problems. It is a little difficult to describe, but I shall try and do so briefly here. Assuming we start with a Radiant site which is stored in the database, but not yet on the filesystem, and the project is under svn control. First, we run: rake file_system:save which saves all layouts, snippets and pages to the file system, within a /design directory. Now suppose we run: svn add design svn commit -m Captured site on file_system Now the contents of the /design directory is under version control. A side effect of this, is that every subdirectory beneath design contains a hidden .svn directory. Suppose you make further changes to the site through the Radiant admin, then, to keep things in sync, you run `rake file_system:save` again. [Here is where it gets messy:] If your changes included the deletion of a page, then the file_system:save action should delete the directory on your file system corresponding to the page that was deleted. In doing so, it will delete the hidden .svn directory which subversion was using to track the contents of that directory. Subversion complains when a directory goes missing which it thinks should be there. When I found myself in this position, I was unable to commit my latest revision. I think I got around the problem in the end, by doing `svn up` to restore the directory that had been deleted by running `rake file_system:save`, and then I deleted that directory by hand, using the `svn rm /design/pages/page-to-be- deleted` command. (I am no expert with svn, so perhaps I'm doing it wrong?) To make the file_system:save action play well with subversion, I am thinking it would probably be necessary to use `svn rm` within the rake task, rather than calling ruby's `FileUtils.rm()` method, but only if the directory contains a .svn/ directory. I've been scratching my head over this for a while, and would really appreciate any thoughts on the matter. Cheers, Drew I've been meaning to write to the list about file_system for a while now. I wrote to Drew and praised him for it and he let me know that it was Sean's invention. Cheers to both of you, nice work. I played around with it in development to discover that if I created a single file for a snippet and then had it load to the DB, it would delete all others. I didn't read the documentation closely, so it was a simple mistake, but I expected it to be non-destructive unless I told it to be. I'm curious about what others think of this. I would expect that when I tell it to load my files to the database, it would just load them, not destroy everything and then load them. I'd prefer that that be a rake argument. Also, as I worked with it, I found it made more sense to be file_system:to_db and file_system:to_files because 'load' and 'save' just doesn't seem clear enough to me and I kept forgetting which was which. And while I'm thinking of it, I would also just make it radiant:to_files and radiant:to_db, but that matters less to me. Also, for anyone else using it, I've been running the tasks during my capistrano deployments. So my previous release will get file_system:to_files and then my current release gets file_system:to_db. That way, in case there have been changes to the DB and I destroy them with my deployment, I can go back to the previous release to undo the problem. -Jim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extension Development in Git
Why not just use tags and branches? script/extension install foo --tag=0.5 Sean Jim Gay wrote: It strikes me that this would be best handled in the extension registry so that each author could handle extension releases as he/she pleases. So script/extension could grab whatever is marked as the latest by default or take an argument for a particular release (which would be set by the author in the registry). On Oct 5, 2008, at 3:36 PM, Marty Haught wrote: I've been wondering how best to maintain stable and unstable branches of an extension in Git. Traditionally you'd keep the master as 'trunk' which would be considered unstable and you'd tag official releases. We could use this approach but I'm wondering how best this works with the new radiant extension install script. Would it be better to get master as the current official release and make a branch, say edge, that is the development portion? Cheers, Marty ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extension Development in Git
Sounds fine to me, but how would that work with extensions that are downloaded? On Oct 5, 2008, at 4:23 PM, Sean Cribbs wrote: Why not just use tags and branches? script/extension install foo --tag=0.5 Sean Jim Gay wrote: It strikes me that this would be best handled in the extension registry so that each author could handle extension releases as he/ she pleases. So script/extension could grab whatever is marked as the latest by default or take an argument for a particular release (which would be set by the author in the registry). On Oct 5, 2008, at 3:36 PM, Marty Haught wrote: I've been wondering how best to maintain stable and unstable branches of an extension in Git. Traditionally you'd keep the master as 'trunk' which would be considered unstable and you'd tag official releases. We could use this approach but I'm wondering how best this works with the new radiant extension install script. Would it be better to get master as the current official release and make a branch, say edge, that is the development portion? Cheers, Marty ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extension Development in Git
Right. It hasn't happened yet, but I really feel we should be trying to release extensions as gems in situations where a checkout is not feasible. Gems include a lot of the features that we seem to need and we wouldn't be reinventing the wheel. Sean Jim Gay wrote: Sounds fine to me, but how would that work with extensions that are downloaded? On Oct 5, 2008, at 4:23 PM, Sean Cribbs wrote: Why not just use tags and branches? script/extension install foo --tag=0.5 Sean Jim Gay wrote: It strikes me that this would be best handled in the extension registry so that each author could handle extension releases as he/she pleases. So script/extension could grab whatever is marked as the latest by default or take an argument for a particular release (which would be set by the author in the registry). On Oct 5, 2008, at 3:36 PM, Marty Haught wrote: I've been wondering how best to maintain stable and unstable branches of an extension in Git. Traditionally you'd keep the master as 'trunk' which would be considered unstable and you'd tag official releases. We could use this approach but I'm wondering how best this works with the new radiant extension install script. Would it be better to get master as the current official release and make a branch, say edge, that is the development portion? Cheers, Marty ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extension Development in Git
On Oct 5, 2008, at 3:36 PM, Marty Haught wrote: I've been wondering how best to maintain stable and unstable branches of an extension in Git. Traditionally you'd keep the master as 'trunk' which would be considered unstable and you'd tag official releases. We could use this approach but I'm wondering how best this works with the new radiant extension install script. Would it be better to get master as the current official release and make a branch, say edge, that is the development portion? I don't know what method will work well for you, and really that's the important part. However, the way the git repository for git (git.git) works is that it has three main branches: - maint: This contains only bugfixes to the previous (tagged) release. - master: Fairly well tested features. - next: Any new changes that are ready for wide-spread testing. Usually stable, but occasionally breaks. The way development is merged into these branches in git.git is somewhat intricate, but an interesting lesson on how development can be done in git. (It is partially described in the regular A note from the maintainer messages on the git mailing list. [1]) Git has these many layers of branches because of the fairly large volume of developers and testers on its list. I would personally recommend that any published repository have at least two branches, a stable and unstable, in addition to the tagged releases. It's always good to be able to publish quick bug fixes separate from new development. Whether master is your unstable and you keep a maint for fixes, or master is stable and you keep a next (or edge) for development is up to you. (For that matter, there is nothing special about the master branch in git... You could have stable and unstable and no master. Which one would be downloaded by default by your users is based on the HEAD link in the repository.) ~~ Brian [1] http://lists-archives.org/git/665040-a-note-from-the-maintainer.html ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] New Radiant Site
On Fri, Oct 3, 2008 at 10:58 PM, Gabriel Lamounier [EMAIL PROTECTED]wrote: Hi there, This message is just to tell you about a new site powered by radiant. Looks good. Nice and bright. I can't really comment on the text. English is my only language. I have one of my own to share as well: www.goodtastewithtanji.com Cheers, Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
