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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
16 matches
Mail list logo
