> What ya reckon? Any suggestions on a better approach? Worth > contributing something like this back to the plugin?
Looks good to me. A couple other ideas might be support for :if or :unless options, or maybe a block for completely custom validations using validates_each.
For the record, I'm not opposed to opening up commit access even more. I'd like to eventually go with a git repo and give out public keys to folks that want them. Rubinius style.
> > What ya reckon? Any suggestions on a better approach? Worth > > contributing something like this back to the plugin?
> Looks good to me. A couple other ideas might be support for :if or > :unless options, or maybe a block for completely custom validations > using validates_each.
> For the record, I'm not opposed to opening up commit access even more. > I'd like to eventually go with a git repo and give out public keys to > folks that want them. Rubinius style.
> Looks good to me. A couple other ideas might be support for :if or > :unless options, or maybe a block for completely custom validations > using validates_each.
I don't need them, but if other people want to tell me what they'd need I'm happy to implement it.
If we're going the route of supporting standard AR validation options then I'd say scrap the validates_attachment convenience method and have 3 separate:
which act like standard AR validations (i.e. you can specify :if, :unless, :message, etc)
> For the record, I'm not opposed to opening up commit access even more. > I'd like to eventually go with a git repo and give out public keys to > folks that want them. Rubinius style.
I'd dig that. You could set up a simple post-commit hook on the definitive git repo master branch that pushes to your SVN for standard plugin install etc
> > Looks good to me. A couple other ideas might be support for :if or > > :unless options, or maybe a block for completely custom validations > > using validates_each.
> I don't need them, but if other people want to tell me what they'd > need I'm happy to implement it.
> If we're going the route of supporting standard AR validation options > then I'd say scrap the validates_attachment convenience method and > have 3 separate:
I'm all for that actually. The validates_attachment thing was thrown in become someone wanted to do their own thing and didn't want the validations to be automatic.
> > For the record, I'm not opposed to opening up commit access even more. > > I'd like to eventually go with a git repo and give out public keys to > > folks that want them. Rubinius style.
> I'd dig that. You could set up a simple post-commit hook on the > definitive git repo master branch that pushes to your SVN for standard > plugin install etc
Evan is supposedly working on a good svn mirroring script for git, so I plan to use that. If you really want access before then, let me know. There's no telling when the script will be ready and when I'll have a chance to set everything up...
>> If we're going the route of supporting standard AR validation options >> then I'd say scrap the validates_attachment convenience method and >> have 3 separate:
> I'm all for that actually. The validates_attachment thing was thrown > in become someone wanted to do their own thing and didn't want the > validations to be automatic.
cool yeah I figured something like that. PDI'ing under way.
> Evan is supposedly working on a good svn mirroring script for git, so > I plan to use that. If you really want access before then, let me > know. There's no telling when the script will be ready and when I'll > have a chance to set everything up...
> For the record, I'm not opposed to opening up commit access even more. > I'd like to eventually go with a git repo and give out public keys to > folks that want them. Rubinius style.
A somewhat related but unrelated question: how the hell do you git-svn clone a repo that doesn't use trunk/tags/branches? I'm trying to git- svn clone attachment_fu to submit a bunch of patches and can't for the life of me find a combination of command line args that does what I need.
> > For the record, I'm not opposed to opening up commit access even more. > > I'd like to eventually go with a git repo and give out public keys to > > folks that want them. Rubinius style.
> A somewhat related but unrelated question: how the hell do you git-svn > clone a repo that doesn't use trunk/tags/branches? I'm trying to git- > svn clone attachment_fu to submit a bunch of patches and can't for the > life of me find a combination of command line args that does what I > need.
On Dec 5, 5:44 pm, Tim Lucas <t.lu...@toolmantim.com> wrote:
> On 04/12/2007, at 1:40 AM, Rick Olson wrote:
> > For the record, I'm not opposed to opening up commit access even more.
> > I'd like to eventually go with a git repo and give out public keys to
> > folks that want them. Rubinius style.
> A somewhat related but unrelated question: how the hell do you git-svn
> clone a repo that doesn't use trunk/tags/branches? I'm trying to git-
> svn clone attachment_fu to submit a bunch of patches and can't for the
> life of me find a combination of command line args that does what I
> need.
No clue, my git-fu is extremely weak. I guess treat the main
attachment_fu dir as the trunk?
|
