Re: [HACKERS] pgsql-hackers@postgresql.org
Rob Butler wrote: ... SVN also has a number of nice features like atomic commits, versioning directories, etc. Still, subversion identifies file content by it's location in the directory tree which makes the directory versioning a lot less useful than it could have been. Renaming directories or even renaming files creates havoc if you have several simultanious branches that need to be merged at some point. Serious design flaw IMHO. When will subversion be able to *really* rename or move an element as opposed to just remove and add? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgsql-hackers@postgresql.org
Rob Butler wrote: [details of some SVN features] please see reecent debates on the topic of SCM systems. "Those who do not remember the debates on the mailing lists are bound to repeat them." cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] pgsql-hackers@postgresql.org
> > >2) As long as we're using CVS, the only way to > organize autonomous project > >teams that have authority over their special areas > but no ability to change > >central code is to "push out" projects to separate > CVS trees. > > > > > This has never been an issue before, AFAIK, nobody > with commit privliges > in a separate > package has ever changed the code where they weren't > supposed to. > > To sum this up; the arguments presented are: > > 1) The tarball is/was too big however nobody ever > complained. > 2) CVS does not allow different groups to have > commit privliges, but > nobody has ever violated the trust > FYI, subversion w/apache allows you to control access permissions. So you can have separate branches/sub-trees with different write permissions for different developers. Also, subversion does a fairly decent job of supporting the same command line options as CVS, so from the end user side it is fairly close to being a drop in replacement, because you don't need to re-learn too much. Of course there is the conversion from CVS to SVN, which is not necessarily easy and definetly not quick/simple. SVN also has a number of nice features like atomic commits, versioning directories, etc. Later Rob __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] pgsql-hackers@postgresql.org
On Sun, Jun 22, 2003 at 09:01:35PM -0700, Sean Chittenden wrote: > As things stand, because O_DIRECT is an execution fast path through > the vfs subsystem, I expect the speed difference to be greater on > faster HDDs with high RPMs than on slower IDE machines at only > 5400RPM... thus trivializing any benchmark I'll do on my laptop. And > actually, if the app can't keep up with the disk, I bet the fs cache > case will be faster. If the read()'s are able to keep up at the rate > of the HDD, however, this could be a big win in the speed dept, but if > things lag for an instant, the platter will have to make another > rotation before the call comes back to the userland. If it would help, I have a quad xeon-550 with a 4 drive raid5 and 2 drive mirror (all SCSI, 7200RPM I think) available. -- Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
