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: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
