Re: [HACKERS] [PATCHES] CVS should die
On Sat, 06 Nov 2004 11:53:13 +0100, Thomas Hallgren wrote: > Andrew McMillan wrote: >> Switching to Arch is more work, but it also offers a lot more benefits - >> including the opportunity for individuals to maintain their own trees, >> and be able to work out which patchsets from someone else's tree have >> not been applied. If anything is going to become the open-source >> BitKeeper it will be this, I think. >> > For those interested in SVN versus arch, I found the following from Tom > Lord (the guy behind Arch) > > http://web.mit.edu/ghudson/thoughts/diagnosing > > and a reply from Greg Hudson (SVN developer) > > http://web.mit.edu/ghudson/thoughts/undiagnosing. > There is a fairly detailed comparison in the GNU Arch wiki as well. http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison> Note: if you're a postgres committer you may have more luck seeking out your nearest SCM advocate -- almost all of them would regard Postgres migrating to their preferred SCM as a 'win' -- let them work for you by walking you through things. Cheers, Anand ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] CVS should die
Ian Barwick wrote: > flat-file based backend ... and the docs mention possible issues with scalability. My impression from being on the Subversion mailing lists: The FSFS backend (flat-file system) scalability issues remain largely theoretical. In practice, it appears to work at least as well as BDB. Some performance issues with having many small files as part of the back-end repository implementation (which FSFS does) are more likely to manifest themselves on some filesystems that have trouble with that condition. Such filesystems seem to mainly exist for Windows. Unix systems seem much more immune to that type of degradation. Heikki Linnakangas wrote: > Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but then growth will slow markedly, so making a comparison for a repository that will continue to grow is difficult.) If you are interested in some significant-sized projects that are known to use Subversion, some are listed on the testimonials page: http://subversion.tigris.org/propaganda.html I'm just a happy user of both Subversion and PosgreSQL. -Travis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] CVS should die
Andrew McMillan wrote: Switching to Arch is more work, but it also offers a lot more benefits - including the opportunity for individuals to maintain their own trees, and be able to work out which patchsets from someone else's tree have not been applied. If anything is going to become the open-source BitKeeper it will be this, I think. For those interested in SVN versus arch, I found the following from Tom Lord (the guy behind Arch) http://web.mit.edu/ghudson/thoughts/diagnosing and a reply from Greg Hudson (SVN developer) http://web.mit.edu/ghudson/thoughts/undiagnosing. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 2004-11-05 at 15:37 -0500, Tom Lane wrote: > > One of the reasons I'm disinclined to move is that none of the proposed > alternatives seem especially, um, mature. AFAIK this project has never > had CVS lose any data in the eight years we've used it. I'd want a > comparable level of trust in any replacement SCM, and I haven't got it. A very sane reason. I've lost my share of stuff with SVN in trialling it, but we are switching our company over to Arch, which seems to offer significantly more benefits. From our trialling of it, I think it has a more robust and mature repository structure too. Watching the PostgreSQL team developing I would think that Arch would provide much better support for the developers than SVN would. Switching to Arch is more work, but it also offers a lot more benefits - including the opportunity for individuals to maintain their own trees, and be able to work out which patchsets from someone else's tree have not been applied. If anything is going to become the open-source BitKeeper it will be this, I think. Cheers, Andrew. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 Planning an election? Call us! - signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [PATCHES] CVS should die
Greg Stark said: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> This just reinforces Tom's well-made point about maturity/stability. I >> rejected using SVN on another project a few months ago for just this >> sort of reason. > > I'm not sure what this says about maturity, you realize read-only > access to CVS also does writes to the repository? There are patches to > change this floating around but it's never been merged "upstream" > because there is no "upstream" maintainer any more. I guess if you want > mature software you can't get any more mature than using orphaned > packages. > I am painfully aware of CVS's behaviour - it's given us plenty of grief getting it right on pgfoundry, as well giving me occasional grief w.r.t. other repositories I am responsible for. CVS is on the way out, for plenty of very good reasons. It is past its use-by date. I don't think anyone seriously disagrees with that. Choosing when to switch to an alternative, and what the alternative will be, is the issue. For example, unless I'm wrong there is not yet a subversion equivalent of CVSup. That's something I would personally be very reluctant to lose. 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])
Re: [HACKERS] [PATCHES] CVS should die
Greg Stark wrote: > > Heikki Linnakangas wrote: > > > Interestingly, the subversion repository is 585MB, and the CVS > > repository is only 260MB, > > So apparently this is a limitation of svn2cvs. It uses a lot more space to > represent tags and branches than would be required if they had been created in > svn directly. Unfortunately it's a hard problem to solve any better than it > is. > > > Markus Bertheau wrote: > > > >> Here's what the subversion book has to say about that: > >> > >> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A > >> > >> We use svn over ssh and recently switched to fsfs because of the umask > >> problem and because read-only access to bdb causes writes to the > >> database. > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > This just reinforces Tom's well-made point about maturity/stability. I rejected > > using SVN on another project a few months ago for just this sort of reason. > > I'm not sure what this says about maturity, you realize read-only access to > CVS also does writes to the repository? There are patches to change this > floating around but it's never been merged "upstream" because there is no > "upstream" maintainer any more. I guess if you want mature software you can't > get any more mature than using orphaned packages. When software reaches perfection, it doesn't need a maintainer. (Bruce ducks for cover.) LOL -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] CVS should die
Heikki Linnakangas wrote: > Interestingly, the subversion repository is 585MB, and the CVS > repository is only 260MB, So apparently this is a limitation of svn2cvs. It uses a lot more space to represent tags and branches than would be required if they had been created in svn directly. Unfortunately it's a hard problem to solve any better than it is. > Markus Bertheau wrote: > >> Here's what the subversion book has to say about that: >> >> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A >> >> We use svn over ssh and recently switched to fsfs because of the umask >> problem and because read-only access to bdb causes writes to the >> database. Andrew Dunstan <[EMAIL PROTECTED]> writes: > This just reinforces Tom's well-made point about maturity/stability. I rejected > using SVN on another project a few months ago for just this sort of reason. I'm not sure what this says about maturity, you realize read-only access to CVS also does writes to the repository? There are patches to change this floating around but it's never been merged "upstream" because there is no "upstream" maintainer any more. I guess if you want mature software you can't get any more mature than using orphaned packages. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
Markus Bertheau wrote: Ð ÐÑÐ, 05.11.2004, Ð 21:40, Heikki Linnakangas ÐÐÑÐÑ: On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but then growth will slow markedly, so making a comparison for a repository that will continue to grow is difficult.) BDB. Here's what the subversion book has to say about that: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A We use svn over ssh and recently switched to fsfs because of the umask problem and because read-only access to bdb causes writes to the database. This just reinforces Tom's well-made point about maturity/stability. I rejected using SVN on another project a few months ago for just this sort of reason. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
Ð ÐÑÐ, 05.11.2004, Ð 21:40, Heikki Linnakangas ÐÐÑÐÑ: > On Fri, 5 Nov 2004, Travis P wrote: > > > Heikki Linnakangas wrote: > >> Interestingly, the subversion repository is 585MB, and the CVS repository > > is only 260MB, > > > > BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend > > tends to pre-allocate space though, so maybe there was a big jump, but then > > growth will slow markedly, so making a comparison for a repository that will > > continue to grow is difficult.) > > BDB. Here's what the subversion book has to say about that: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A We use svn over ssh and recently switched to fsfs because of the umask problem and because read-only access to bdb causes writes to the database. -- Markus Bertheau <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but then growth will slow markedly, so making a comparison for a repository that will continue to grow is difficult.) BDB. - Heikki ---(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
Re: [HACKERS] [PATCHES] CVS should die
Ian Barwick <[EMAIL PROTECTED]> writes: > Aha, glad I'm not the only one. Version 1.1 has a flat-file based > backend which is not prone to BDB-permission-related problems, see: > http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 . > It's only been around a few months though and the docs mention > possible issues with scalability. One of the reasons I'm disinclined to move is that none of the proposed alternatives seem especially, um, mature. AFAIK this project has never had CVS lose any data in the eight years we've used it. I'd want a comparable level of trust in any replacement SCM, and I haven't got it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heikki Linnakangas wrote: | Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think | TortoiseSVN is a fork of that. I didn't know the existence, is not even listed in the subproject on CVS home page, I discovered TortoiseSVN on the Subversion home page. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBi9bJ7UpzwH2SGd4RAgraAKCcNLaMJPPjVxfqRQ1yGG2+GssiAACeJFg3 zULofgK2ouUum3wNSjUmG3U= =Bq/a -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004, Gaetano Mendola wrote: Heikki Linnakangas wrote: FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. Mmm, do you mean createing periodically "snapshot"? Yes this could be a good idea. No, I mean that each project could choose to use either cvs or svn, like they do at Apache. Sure, if you could have both, that would be even better. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? I don't know about the server, but for sure what is more important here is the client side and now that the win environment matter more then before, I have to say that TortoiseSVN ( tortoisesvn.tigris.org ) is much better then WinCVS. True. Looking at the Subversion downloads page, they seem to have binaries for various Linux distributions, FreeBSD, NetBSD and OpenBSD, Solaris, Mac OS X and Win32. According to the supported platforms chapter in pgsql documentation, we also support AIX, BSD/OS, HP-UX, IRIX, Tru64 UNIX, UnixWare, and Linux on Alpha, arm41, m64, MIPS, PPC, S/390 and Sparc. Developers on those platforms would have to compile subversion themselves, or compile pgsql from source tarballs. Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think TortoiseSVN is a fork of that. - Heikki ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004 16:22:55 +0100, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: > > I'll repeat an observation I made (more or less) last time we had this > > discussion: the loudest voice in it belongs to those who actually use > > the repository most. When Tom or Bruce or Peter (for example) tell us we > > need to change I'll take lots more notice. > > I'm certainly open to considering subversion, although I have a certain > traumatic experience with it that may or may not be related to the BDB > backend that it uses. Aha, glad I'm not the only one. Version 1.1 has a flat-file based backend which is not prone to BDB-permission-related problems, see: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 . It's only been around a few months though and the docs mention possible issues with scalability. Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] CVS should die
Heikki Linnakangas wrote: I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no problems. Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, so apparently Subversion is not very good at compressing the repository. Not that it matters, though. FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. Mmm, do you mean createing periodically "snapshot"? Yes this could be a good idea. I also agree with Andrew's observation that it's really up to the committers since they are the ones that have to work with whatever system we have. That's true, but is really sad see Tom Lane think twice to move a file or not because CVS. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? I don't know about the server, but for sure what is more important here is the client side and now that the win environment matter more then before, I have to say that TortoiseSVN ( tortoisesvn.tigris.org ) is much better then WinCVS. Regards Gaetano Mendola ---(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
Re: [HACKERS] [PATCHES] CVS should die
Heikki Linnakangas wrote: On Fri, 5 Nov 2004, Gaetano Mendola wrote: Peter Eisentraut wrote: I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I good very start point is see if cvs2svn can handle the postgresql CVS without errors. I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no problems. Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, so apparently Subversion is not very good at compressing the repository. Not that it matters, though. Subversion, I believe uses SleepycatDb (eg Db4). Thus it isn't flat files like CVS. I also agree with Andrew's observation that it's really up to the committers since they are the ones that have to work with whatever system we have. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? Doubtful. Also there are known issues with Subversion on >FC1 if you are running newer versions of it. You have to compile specially with --without-posix-mutexes (I think that was the flag). Sincerely, Joshua D. Drake - Heikki ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 5 Nov 2004, Gaetano Mendola wrote: Peter Eisentraut wrote: I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I good very start point is see if cvs2svn can handle the postgresql CVS without errors. I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no problems. Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, so apparently Subversion is not very good at compressing the repository. Not that it matters, though. FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. I also agree with Andrew's observation that it's really up to the committers since they are the ones that have to work with whatever system we have. I like subversion very much, but one thing that troubles me a bit is the number of extra libraries required to compile and run it. Also, is there pre-compiled binaries for all the platforms that PostgreSQL supports? - Heikki ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] CVS should die
Peter Eisentraut wrote: Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository most. When Tom or Bruce or Peter (for example) tell us we need to change I'll take lots more notice. I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I good very start point is see if cvs2svn can handle the postgresql CVS without errors. Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] CVS should die
Peter Eisentraut wrote: I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I agree. We (the pgfoundry admins) will see what can be done - no promises at this stage. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] CVS should die
Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: > I'll repeat an observation I made (more or less) last time we had this > discussion: the loudest voice in it belongs to those who actually use > the repository most. When Tom or Bruce or Peter (for example) tell us we > need to change I'll take lots more notice. I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] CVS should die
Andrew Dunstan wrote: Neil Conway wrote: Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. Yeah. I see these considerations as being important: . does tool x do what we need? . is tool x FOSS software? . is the benefit to be gained from moving to tool x worth the pain involved? Duh! Bad wording on my part. I didn't mean that their future use of SQL backend should be a criteria. So "compelling reason" was a bad choice of words. What I meant was, that at some point, we might be able to help the SVN people reach their SQL objective and at the same time push for PostgreSQL as the best choice. If PostgreSQL uses SVN (for the reasons mentioned by Andrew), then some knowledge will be gained and relationships established that might make such a collaboration very natural. Once a PostgreSQL based backend is well tested and very stable, PostgreSQL can make the switch to use it for their own production. From an SVN standpoint, it must be a perfect reference to be able to say "Look, PostgreSQL uses SVN with their own database to store their own code". A better proof of concept doesn't exist! From a PostgreSQL standpoint? Well SVN already have a high amount of users and it is growing rapidly, i.e. the visibility is great. It also struck me that the requirements for an SCM backend store must be especially well handled by an MVCC type system. New data is added frequently but very rarely updated or deleted. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] CVS should die
Neil Conway wrote: Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. Yeah. I see these considerations as being important: . does tool x do what we need? . is tool x FOSS software? . is the benefit to be gained from moving to tool x worth the pain involved? I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository most. When Tom or Bruce or Peter (for example) tell us we need to change I'll take lots more notice. I have little doubt that we will one day move away from CVS. What we will move to is still open - and I don't yet see a reason to rush into the arms of Subversion. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a "compelling reason" to use a particular version control system as I can imagine. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PATCHES] CVS should die (was: Possible make_oidjoins_check ...)
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Can this be discussed for 8.1? It's been discussed, and rejected, several times already. There aren't any alternatives that are enough better than CVS to be worth the changeover effort. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
