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.

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.

Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to