Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
This doesn't really answer the question of what tool Postgres might change to, but it seems that Subversion is a good tool one should consider. And by golly, CVS is bad. Just consider the cons having to forbid renames in all but the most necessary cases it just invites cruft into any project. Interesting reading: http://better-scm.berlios.de/comparison/comparison.html http://zooko.com/revision_control_quick_ref.html Cheers, Steve ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
The intuitive understanding of a file is certainly something like a file called 'baz.c' residing at 'foo/bar/', which contains the BAZ subsystem. Now, when renaming/moving a file such an intuitive understanding is partially lost. UI-wise that's a problem which I haven't ever seen solved well. However, other SCM systems such as Subversion and Continuus (and our to-be-released system Maint, and certainly others) treat files as unique entities unrelated to their path, and thus don't have problems with moves. With regards to modes of working this, it boils down to two methods. One is treating directories as first class entities (opposed to CVS which treats dirs as semi-relevant appendices to real files), versioned to contain a list of children, or simpler yet, to store the parent directory as an meaningful attribute of an object. Both methods have their pros and cons, the latter is somehow simpler to intuitively grasp for people. This doesn't really answer the question of what tool Postgres might change to, but it seems that Subversion is a good tool one should consider. And by golly, CVS is bad. Just consider the cons having to forbid renames in all but the most necessary cases it just invites cruft into any project. d. -- David Helgason, Business Development et al., Over the Edge I/S (http://otee.dk) Direct line +45 2620 0663 Main line +45 3264 5049 On 4. nov 2004, at 20:41, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons. (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(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] CVS should die (was: Possible make_oidjoins_check ...)
On Thu, 4 Nov 2004, Alvaro Herrera wrote: On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Why not move it to src/tools, so no one gets the impression that it is user code? I thought about that earlier, but concluded it wasn't worth the loss of CVS history. why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
Marc G. Fournier [EMAIL PROTECTED] writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons. (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
On Thu, 4 Nov 2004, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. Erk, yes, good point ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
On Thu, Nov 04, 2004 at 02:41:08PM -0500, Tom Lane wrote: (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) I understood that the whole point of subversion was mostly to make moving files easier. It's number two in the feature list at the subversion home page. They say they version meta-data. A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
Hi, On Thursday 04 November 2004 20:41, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons. (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend Advocacy Yes, some do. At least SVN (Subversion) can handle moves very well, and especially it doesn't loose history on moves/renames. SVN holds it's repo entries in a database like 'filesystem', which can be backed by BDB4 or flat files (as of 1.1). SVN has proven to be stable in many OSS projects, and vastly superior over CVS especially in handling multi-GB projects containing binary files in our company. I refrain from listing all the advantages, if interested, have a look for yourself at http://subversion.tigris.org /Advocacy Having one file in the repo per working copy file like with CVS is an obvious, but also obviously limited approach. Greetings, Jörg -- Leading SW developer - S.E.A GmbH Mail: [EMAIL PROTECTED] WWW: http://www.sea-gmbh.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
On Fri, 5 Nov 2004 07:02 am, Marc G. Fournier wrote: On Thu, 4 Nov 2004, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. Erk, yes, good point ... You could always, physically copy the file to the new location. Giving you all the history in the new location and run CVS delete on the only location. I can't see how this is too different from the cvs remove/cvs add. However you get to keep the history as well as keeping the old version. The second problem still exists where it's in 2 locations in previous releases. unless you cvs remove the new copy from those branches as well. As always CVS is a bit messy with these things, but just throwing ideas on the pile that might work. Regards Russell Smith ---(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
