Re: [HACKERS] CVS should die
[EMAIL PROTECTED] (Travis P) wrote in message news:[EMAIL PROTECTED]... Misinforming the user on rename with local changes [EMAIL PROTECTED] news://news.gmane.org:119/[EMAIL PROTECTED] Might be easier to read with a browser here: http://svn.haxx.se/dev/archive-2004-11/index.shtml Yes, looks like it could be a potential problem/inconvenience if a file is both moved and altered simultaneously. You guys should check out the software that I developed called Meta-CVS. It creates a version control system that has directory structure versioning, over top of the file versioning semantics provided by CVS. Meta-CVS does not have problems with these corner cases, by design. I see the risk of problems as similar to those that if two people edit the same section of the same file at the same time, complicated conflicts could emerge. In Meta-CVS, conflicts in the directory structure are exactly like these conflicts, because the directory structure is marked up as a straightforward text document. When conflicts occur, you can read that document and it's obvious that one user wanted to rename foo.c to src/foo.c, whereas another one wanted to rename it to foobar.c. Meta-CVS completely separates the directory structure from the files, in the classic way: just like Unix file systems, and network file systems like NFS and others. A file is known by an 128 bit identifier encoded as text in hexadecimal. So for example, even picking up a deletion to a locally modified file is safe. Suppose you have been editing a document foo.txt, do a ``mcvs up'' and it's deleted. Your changes are still safe and can be committed. All that happened was that your foo.txt was unlinked from the directory structure. The real object, still exists, and has all your changes. It can be committed to CVS. Independently of that action, you can re-introduce your object into the directory structure: just change the markup document (a file called MAP in the MCVS directory at the root of your project) and then run ``mcvs up''. Meta-CVS will notice the change, and link the file into the appropriate place, as requested by the new markup. You can commit that markup change, and the file will reappear in people's sandboxes when they pick it up. It is too bad the Subversion design didn't anticipate this such that it's not a problem at all, but in many environments, it may not be much of an issue. Fortunately, I anticipated the problem before I laid down the first line of code. ---(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] CVS should die
Travis P wrote: Thomas (Hallgren): Unfortunately, my efforts to get Thunderbird to do something useful with that URL have been unsuccessful and I can't find the thread on the (usable) mailing list archive ( don't use the tigris.org archive; use http://svn.haxx.se/ ). Thanks Travis. I'm not at all friend with Tigris mailing list archives and I wasn't aware of haxx.se. Here are the relevant links: http://svn.haxx.se/dev/archive-2004-11/0505.shtml http://svn.haxx.se/users/archive-2004-11/0433.shtml http://svn.haxx.se/users/archive-2004-11/0445.shtml Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS should die
Tom Lane wrote: ... There aren't any alternatives that are enough better than CVS to be worth the changeover effort. I've done some research over the last couple of days for a fairly big project where we face the challenges of breaking up a monolith into modules and consequently will be forced to move a lot of files. I now second Tom's opinion. Here's why: Subversion doesn't move files. They copy and delete. So if you have parallel work on a file that is moved, you are headed for problems. See threads: Question about rename on [EMAIL PROTECTED] news://news.gmane.org:119/[EMAIL PROTECTED] and Misinforming the user on rename with local changes [EMAIL PROTECTED] news://news.gmane.org:119/[EMAIL PROTECTED] What I find especially intriguing is that although Subversion have version controlled directories, they still identify the content of the files using the location in the repository rather than using a globally unique identifier. Didn't they anticipate files being moved around and perhaps linked? This thread started due to CVS problems with moving files and Subversion will perhaps get there eventually but IMHO they are certainly not there yet. GNU-Arch seems promising in some respects. It really can rename files and track them using an id, but it doesn't run on Windows without Cygwin (and even then not too well it seems). Personally I dislike the fact that the author seems somewhat religious about free software and hostile towards Windows instead of focusing on delivering a portable solution. In my case, the fact that GNU-Arch is not portable is reason enough to discard it as a viable alternative and I think it would be unfortunate if PostgreSQL locked Windows users out from repository access. The other Open Source alternatives are, IMHO not mature enough to be considered for serious projects yet. I wish ClearCase was fast, free, and suitable for distributed development :-) Unfortunately it's slow, expensive, and extremely network intensive. My approach will be to wait and perhaps contribute to Subversion if I get some time left. They really need a great database backend. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS should die
Thomas Hallgren wrote: GNU-Arch seems promising in some respects. It really can rename files and track them using an id, but it doesn't run on Windows without Cygwin (and even then not too well it seems). Personally I dislike the fact that the author seems somewhat religious about free software and hostile towards Windows instead of focusing on delivering a portable solution. In my case, the fact that GNU-Arch is not portable is reason enough to discard it as a viable alternative and I think it would be unfortunate if PostgreSQL locked Windows users out from repository access. s/unfortunate/totally unacceptable/ cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS should die
On Nov 13, 2004, at 6:20 PM, Thomas Hallgren wrote: Question about rename on [EMAIL PROTECTED] news://news.gmane.org:119/[EMAIL PROTECTED] Thomas (Hallgren): Unfortunately, my efforts to get Thunderbird to do something useful with that URL have been unsuccessful and I can't find the thread on the (usable) mailing list archive ( don't use the tigris.org archive; use http://svn.haxx.se/ ). Misinforming the user on rename with local changes [EMAIL PROTECTED] news://news.gmane.org:119/[EMAIL PROTECTED] Might be easier to read with a browser here: http://svn.haxx.se/dev/archive-2004-11/index.shtml Yes, looks like it could be a potential problem/inconvenience if a file is both moved and altered simultaneously. I see the risk of problems as similar to those that if two people edit the same section of the same file at the same time, complicated conflicts could emerge. You could avoid this problem using Lock-Modify-Unlock rather than Copy-Modify-Merge. Some people do. Others (many CVS users) choose the productivity gains by using Copy-Modify-Merge and then deal with the eventual problem when/if it shows up. It is too bad the Subversion design didn't anticipate this such that it's not a problem at all, but in many environments, it may not be much of an issue. This thread started due to CVS problems with moving files and Subversion will perhaps get there eventually but IMHO they are certainly not there yet. It is worth noting that there is already huge improvement in this area. There's a baby in that bathwater. :-) It's made my life much easier, particularly for Java development where refactoring requires renames and moves of files and directories more often than with some other languages like C/C++. I'm not really advocating a switch if you don't think it's worth it. Just hoping to contribute constructively to the discussion where the worth of the costs/benefits are measured by others. Back to playing with the 8 beta for me, :-) --Travis ---(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 ...)
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
Tom, (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've been working with a few SCM's and IMHO only one of them really handles this really well. That's ClearCase. I'm well aware that ClearCase is not an option but I though it could still be interesting to know how this can be managed when done right. In ClearCase everything (both files and directories) are elements. A directory is a version of an element and it contains versions of other elements. It's not very different from Unix and I-nodes although everything is of course versioned. Subversion claims they handle moves pretty well. When I checked it out, it turns out that a move is a copy (versions and all) followed by a delete, thus maintaining version history at both locations. I'd recommend anyone who think CVS is insufficient due to file moves to investigate subversion. Regards, Thomas Hallgren ---(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
Joerg Hessdoerfer wrote: 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 MoreAdvocacy Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. PostreSQL must be the absolute best choice for that, right? So knowledge of SVN and some future collaboration could perhaps be beneficial for both parties. SVN is also targeted as a CVS replacement and a CVS user will feel very much at home. /MoreAdvocacy Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
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. I have counted three times you have said that in the recent past. IMHO this really screams of changing the SCM tool. Can this be discussed for 8.1? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La felicidad no es mañana. La felicidad es ahora ---(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, 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
Tom Lane wrote: 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. You can also do a repository-side copy of the ,v file to the new location, remove old tags branches from that new copy, and 'cvs delete' the old copy. That preserves history but the file should still show up in the old location (and not also in the new location) when older versions are checked out. In theory. It's all very hairy.. (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.) Subversion deals with this reasonably well. The main difference to CVS is that it does not try to track multiple lines of development in a particular file; instead, you make (internally cheap) copies *within* the repository tree when you branch or tag. Once you have that, it's much easier to track file copies and deletions, as each path in the repository effectively has a linear history. A rename is just a copy and delete. See http://svnbook.red-bean.com/svnbook-1.0/ch04s02.html for some more detail. -O ---(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] 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
Re: [HACKERS] CVS should die
Neil Conway wrote: [CC list trimmed] On Fri, 2004-11-05 at 06:41, 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.) Sure -- just about every next generation OSS version control tool gets this right, or at least does a lot better than CVS -- i.e. svn, monotone, arch, darchs, and possibly others I haven't heard of. Gavin and I have been using Monotone for a few weeks now to manage some development we're doing. I've been really impressed with it -- conceptually, it just makes sense. Unfortunately the implementation is currently too immature to consider moving the main development tree onto, at least for the moment. In SVN there is no concept of Branch, Label and so on, all these operations are performed by copy if you want LABEL your source is enough create a directory and copy all the source in that directory. In order to emulate the way to work of CVS is enough follow these guidelines: http://docs.codehaus.org/display/HAUS/How+to+Organize+a+Subversion+Repository We are migrating from Clearcase to SVN and the only think we are going to miss is the UCM process. 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
