Thread: PGDN and CVS
Hi Dave,
Regarding the PGDN.
- Let’s say we produce a directory with all kinds of static html,images sample sql scripts etc… How do we want to update the whole PGDN within our CVS.
- Do we want to put the static PGDN files in CVS anyway? Should we keep the PGDN files separate not mixing with the current site’s CVS?
Regards,
Gevik.
From: Gevik babakhani [mailto:gevik@xs4all.nl]
Sent: 21 September 2005 10:41
To: pgsql-www@postgresql.org
Cc: Dave Page
Subject: PGDN and CVSHi Dave,
Hi Gevik,
Regarding the PGDN.
- Let’s say we produce a directory with all kinds of static html,images sample sql scripts etc… How do we want to update the whole PGDN within our CVS.
We need a script that will traverse the directory structure and perform the appropriate CVS add/remove operations based on what it finds, and then commits the whole tree. It sounds hard at first thought, but I don't think it is when thought about further - for example, we hierarchically traverse the tree, and for each directory or file we find, we check CVS/Entries to see if it exists in CVS. If not, we do a CVS ADD on it. When we've processed the files, we then go line by line through CVS/Entries, and CVS REMOVE any files or directories that don't exist any more. That should be a relatively trivial perl script for someone familiar with perl.
- Do we want to put the static PGDN files in CVS anyway? Should we keep the PGDN files separate not mixing with the current site’s CVS?
Yes, we do want them in CVS because we build the entire from there & the backend database. we don't want to start pulling in content from additional places as that just makes it much harder to rebuild the servers if there is ever a problem.
Regards, Dave.
> 1. Do we want to put the static PGDN files in CVS > anyway? Should we keep the PGDN files separate not mixing > with the current site's CVS? > > > > Yes, we do want them in CVS because we build the entire from > there & the backend database. we don't want to start pulling > in content from additional places as that just makes it much > harder to rebuild the servers if there is ever a problem. While I agree with you in general, here's a point I'd liek to add. :-) Gevik, if I get your latest blog post right, you are back to a custom CMS and not using Drupal? Then, IMHO, another option is if you can build the site completely with PHP code on our site framework and store all the data in the site database. In this case I see no more reason to store the static pages for this one than there is for the docs or other parts of the site. But this assumes that *all* the code required to maintain the site is in our framework, and we're not relying on an outside CMS. //Magnus
I have hacked with the current framework while ago. I almost know how things work. (Dave has been a great help for my questions...). My plan is to transfer the things I have created with drupal to the current framework also :) I was also thinking of letting everything in the site's database. Why would we want to export things and then re-import them back in the CVS? But then again this is just my opinion. The decisions are on the masters :) Gevik > -----Original Message----- > From: Magnus Hagander [mailto:mha@sollentuna.net] > Sent: Wednesday, September 21, 2005 2:32 PM > To: Dave Page; Gevik babakhani; pgsql-www@postgresql.org > Subject: RE: [pgsql-www] PGDN and CVS > > > 1. Do we want to put the static PGDN files in CVS > > anyway? Should we keep the PGDN files separate not mixing > > with the current site's CVS? > > > > > > > > Yes, we do want them in CVS because we build the entire from > > there & the backend database. we don't want to start pulling > > in content from additional places as that just makes it much > > harder to rebuild the servers if there is ever a problem. > > While I agree with you in general, here's a point I'd liek to add. :-) > > Gevik, if I get your latest blog post right, you are back to a custom > CMS and not using Drupal? Then, IMHO, another option is if you can build > the site completely with PHP code on our site framework and store all > the data in the site database. In this case I see no more reason to > store the static pages for this one than there is for the docs or other > parts of the site. But this assumes that *all* the code required to > maintain the site is in our framework, and we're not relying on an > outside CMS. > > //Magnus
> -----Original Message----- > From: Gevik babakhani [mailto:gevik@xs4all.nl] > Sent: 21 September 2005 13:57 > To: 'Magnus Hagander'; Dave Page; pgsql-www@postgresql.org > Subject: RE: [pgsql-www] PGDN and CVS > > I have hacked with the current framework while ago. I almost > know how things > work. (Dave has been a great help for my questions...). > > My plan is to transfer the things I have created with drupal > to the current > framework also :) > > I was also thinking of letting everything in the site's > database. Why would > we want to export things and then re-import them back in the > CVS? But then > again this is just my opinion. The decisions are on the masters :) Database is fine with me as an alternative to CVS, just as long as it can be generated out into a static format for replication to the front-end servers. What I don't want is something completely separate that requires significant effort to keep synced up, or to recover in the event of a disaster. Regards, Dave
Gevik, > My plan is to transfer the things I have created with drupal to the > current framework also :) Not to discourage you or anything, but I'm extremely skeptical of using a custom CMS not supported by an outside project. What happens if you leave? Why are we re-inventing what 1,000 other CMSes have done before? -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh, I'm not discouraged in anyway... I have just been looking over and over for a CMS that we could use in our project. Time after time I end up with commercial products. And even if they are opensource, they need to be so much customized that one has to put more time in customizing the CMS framework rather than building the actual requirement. > -----Original Message----- > From: Josh Berkus [mailto:josh@agliodbs.com] > Sent: Wednesday, September 21, 2005 8:57 PM > To: pgsql-www@postgresql.org > Cc: Gevik babakhani; 'Magnus Hagander'; 'Dave Page' > Subject: Re: [pgsql-www] PGDN and CVS > > Gevik, > > > My plan is to transfer the things I have created with drupal to the > > current framework also :) > > Not to discourage you or anything, but I'm extremely skeptical of using a > custom CMS not supported by an outside project. What happens if you > leave? Why are we re-inventing what 1,000 other CMSes have done before? > > -- > --Josh > > Josh Berkus > Aglio Database Solutions > San Francisco
Gevik, > I'm not discouraged in anyway... I have just been looking over and over > for a CMS that we could use in our project. Time after time I end up > with commercial products. And even if they are opensource, they need to > be so much customized that one has to put more time in customizing the > CMS framework rather than building the actual requirement. What is it you're trying to implement, exactly, that you don't find supported? Is it the tree structure? Even if existing CMSes require customization, I think it'd be better to work with that project and try to get them involved in the feature. As far as I know, the only CMS you've really tried is Drupal. Both Bricolage and Framewerk are intimate with the PostgreSQL community and could be counted on to work with you. I don't think you even looked at Bricolage after Marc set it up. I also don't think you've evaluated "more time to implement" using valid criteria. If you do a custom CMS, you're going to need to impement all of the common stuff yourself: Authentication User management (including "e-mail me my password, etc.") Approval/rights structures Versioning admin Editors (inc. wyswyg and/or bbcode edit) RSS etc. Did your really add up coding all of the above compared to customizing an existing system? Again, I'm not trying to discourage you, but from my perspective half a CMS is worse than none. --Josh -- --Josh Josh Berkus Aglio Database Solutions San Francisco
I just want to get my hands building :) > -----Original Message----- > From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- > owner@postgresql.org] On Behalf Of Josh Berkus > Sent: Wednesday, September 21, 2005 9:15 PM > To: Gevik babakhani > Cc: pgsql-www@postgresql.org; 'Magnus Hagander'; 'Dave Page' > Subject: Re: [pgsql-www] PGDN and CVS > > Gevik, > > > I'm not discouraged in anyway... I have just been looking over and over > > for a CMS that we could use in our project. Time after time I end up > > with commercial products. And even if they are opensource, they need to > > be so much customized that one has to put more time in customizing the > > CMS framework rather than building the actual requirement. > > What is it you're trying to implement, exactly, that you don't find > supported? Is it the tree structure? > > Even if existing CMSes require customization, I think it'd be better to > work with that project and try to get them involved in the feature. As > far as I know, the only CMS you've really tried is Drupal. > > Both Bricolage and Framewerk are intimate with the PostgreSQL community > and > could be counted on to work with you. I don't think you even looked at > Bricolage after Marc set it up. > > I also don't think you've evaluated "more time to implement" using valid > criteria. If you do a custom CMS, you're going to need to impement all of > the common stuff yourself: > Authentication > User management (including "e-mail me my password, etc.") > Approval/rights structures > Versioning admin > Editors (inc. wyswyg and/or bbcode edit) > RSS > etc. > Did your really add up coding all of the above compared to customizing an > existing system? > > Again, I'm not trying to discourage you, but from my perspective half a > CMS > is worse than none. > > --Josh > > -- > --Josh > > Josh Berkus > Aglio Database Solutions > San Francisco > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
Is this Framewerk the same as www.Framewerk.org? > -----Original Message----- > From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- > owner@postgresql.org] On Behalf Of Josh Berkus > Sent: Wednesday, September 21, 2005 9:15 PM > To: Gevik babakhani > Cc: pgsql-www@postgresql.org; 'Magnus Hagander'; 'Dave Page' > Subject: Re: [pgsql-www] PGDN and CVS > > Gevik, > > > I'm not discouraged in anyway... I have just been looking over and over > > for a CMS that we could use in our project. Time after time I end up > > with commercial products. And even if they are opensource, they need to > > be so much customized that one has to put more time in customizing the > > CMS framework rather than building the actual requirement. > > What is it you're trying to implement, exactly, that you don't find > supported? Is it the tree structure? > > Even if existing CMSes require customization, I think it'd be better to > work with that project and try to get them involved in the feature. As > far as I know, the only CMS you've really tried is Drupal. > > Both Bricolage and Framewerk are intimate with the PostgreSQL community > and > could be counted on to work with you. I don't think you even looked at > Bricolage after Marc set it up. > > I also don't think you've evaluated "more time to implement" using valid > criteria. If you do a custom CMS, you're going to need to impement all of > the common stuff yourself: > Authentication > User management (including "e-mail me my password, etc.") > Approval/rights structures > Versioning admin > Editors (inc. wyswyg and/or bbcode edit) > RSS > etc. > Did your really add up coding all of the above compared to customizing an > existing system? > > Again, I'm not trying to discourage you, but from my perspective half a > CMS > is worse than none. > > --Josh > > -- > --Josh > > Josh Berkus > Aglio Database Solutions > San Francisco > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
Gevik, > I just want to get my hands building :):) Oh, I can understand your frustration. I often feel the same way when dealing with GForge. However, I have a realistic idea on how long it would take to implement all the Administrative Crap We Can't Live Without. > Is this Framewerk the same as www.Framewerk.org? Yes. Looks like Gavin has taken the site down pending the release of the new version. Framewerk doesn't have much of a community (yet) but has the advantage of having the lead developer on this list (hi, Gavin!). It's also taken care of the admin overhead like users and permissions and stuff. So if you can't deal with Bric because it's Perl & Template toolkit, then I'd talk to Gavin about extending Framewerk. But please, please, please don't start from scratch! -- Josh Berkus Aglio Database Solutions San Francisco
Yes, is my pet project. I'll send you some info on the framewerk list. Gavin On Sep 21, 2005, at 12:52 PM, Gevik babakhani wrote: > Is this Framewerk the same as www.Framewerk.org? > > >> -----Original Message----- >> From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- >> owner@postgresql.org] On Behalf Of Josh Berkus >> Sent: Wednesday, September 21, 2005 9:15 PM >> To: Gevik babakhani >> Cc: pgsql-www@postgresql.org; 'Magnus Hagander'; 'Dave Page' >> Subject: Re: [pgsql-www] PGDN and CVS >> >> Gevik, >> >> >>> I'm not discouraged in anyway... I have just been looking over >>> and over >>> for a CMS that we could use in our project. Time after time I end up >>> with commercial products. And even if they are opensource, they >>> need to >>> be so much customized that one has to put more time in >>> customizing the >>> CMS framework rather than building the actual requirement. >>> >> >> What is it you're trying to implement, exactly, that you don't find >> supported? Is it the tree structure? >> >> Even if existing CMSes require customization, I think it'd be >> better to >> work with that project and try to get them involved in the >> feature. As >> far as I know, the only CMS you've really tried is Drupal. >> >> Both Bricolage and Framewerk are intimate with the PostgreSQL >> community >> and >> could be counted on to work with you. I don't think you even >> looked at >> Bricolage after Marc set it up. >> >> I also don't think you've evaluated "more time to implement" using >> valid >> criteria. If you do a custom CMS, you're going to need to >> impement all of >> the common stuff yourself: >> Authentication >> User management (including "e-mail me my password, etc.") >> Approval/rights structures >> Versioning admin >> Editors (inc. wyswyg and/or bbcode edit) >> RSS >> etc. >> Did your really add up coding all of the above compared to >> customizing an >> existing system? >> >> Again, I'm not trying to discourage you, but from my perspective >> half a >> CMS >> is worse than none. >> >> --Josh >> >> -- >> --Josh >> >> Josh Berkus >> Aglio Database Solutions >> San Francisco >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 9: In versions below 8.0, the planner will ignore your desire to >> choose an index scan if your joining column's datatypes do not >> match >> > > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend > Gavin M. Roy 800 Pound Gorilla gmr@ehpg.net
On Wed, Sep 21, 2005 at 11:57:26AM -0700, Josh Berkus wrote: > Gevik, > > > My plan is to transfer the things I have created with drupal to the > > current framework also :) > > Not to discourage you or anything, but I'm extremely skeptical of using a > custom CMS not supported by an outside project. What happens if you > leave? Why are we re-inventing what 1,000 other CMSes have done before? > > -- > --Josh > Gevik, I would like to add my support to Josh's statment. It appears that far too much re-inventing is taking place on the "it's so easy to use and does all we need" Drupal that would already exist in some of the other CMS projects that were cursorily looked at when Drupal was chosen. Bricolage, in particular, has a lot to offer and has a robust development team. Ken
> -----Original Message----- > From: Gevik babakhani [mailto:gevik@xs4all.nl] > Sent: 21 September 2005 20:53 > To: josh@agliodbs.com > Cc: pgsql-www@postgresql.org; 'Magnus Hagander'; Dave Page > Subject: RE: [pgsql-www] PGDN and CVS > > Is this Framewerk the same as www.Framewerk.org? Yes - as you've probably already seen by know Gavin the lead is well known around these parts :-) Actually from what I know of it, it may well be a particularly good choice for this project. My understanding is that it is more of a framework (hence the name I guess!) for building sites on than a ready-to-run CMS, thus giving you many of the boring-to-build bits in a ready to use form, but allowing you to get your hands dirty getting it to work just as required. Regards, Dave.
Agreed :) > -----Original Message----- > From: Josh Berkus [mailto:josh@agliodbs.com] > Sent: Wednesday, September 21, 2005 10:04 PM > To: Gevik babakhani > Cc: pgsql-www@postgresql.org; 'Magnus Hagander'; 'Dave Page' > Subject: Re: [pgsql-www] PGDN and CVS > > Gevik, > > > I just want to get my hands building :):) > > Oh, I can understand your frustration. I often feel the same way when > dealing with GForge. However, I have a realistic idea on how long it > would > take to implement all the Administrative Crap We Can't Live Without. > > > Is this Framewerk the same as www.Framewerk.org? > > Yes. Looks like Gavin has taken the site down pending the release of the > new > version. Framewerk doesn't have much of a community (yet) but has the > advantage of having the lead developer on this list (hi, Gavin!). It's > also > taken care of the admin overhead like users and permissions and stuff. > > So if you can't deal with Bric because it's Perl & Template toolkit, then > I'd > talk to Gavin about extending Framewerk. > > But please, please, please don't start from scratch! > > -- > Josh Berkus > Aglio Database Solutions > San Francisco