Thread: CVS should die (was: Possible make_oidjoins_check ...)
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> 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"
Alvaro Herrera <alvherre@dcc.uchile.cl> 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
On Thu, 4 Nov 2004, Alvaro Herrera wrote: > On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote: >> Peter Eisentraut <peter_e@gmx.net> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> 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
On Thu, 4 Nov 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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 | ajs@crankycanuck.ca In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland
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
Hi, On Thursday 04 November 2004 20:41, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> 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: joerg.hessdoerfer@sea-gmbh.com WWW: http://www.sea-gmbh.com
On Fri, 5 Nov 2004 07:02 am, Marc G. Fournier wrote: > On Thu, 4 Nov 2004, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@postgresql.org> 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
[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. -Neil
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
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" <scrappy@postgresql.org> 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 >
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
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
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
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
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/
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
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
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
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 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
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
On Fri, 5 Nov 2004 16:22:55 +0100, Peter Eisentraut <peter_e@gmx.net> 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 barwick@gmail.com
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
-----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-----
Ian Barwick <barwick@gmail.com> 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
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! -------------------------------------------------------------------------
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
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
> 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
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. <URL: 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
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 users@subversion.tigris.org news://news.gmane.org:119/cmsqci$s9q$1@sea.gmane.org and "Misinforming the user on rename with local changes" dev@subversion.tigris.org news://news.gmane.org:119/419379F3.5070302@ftml.net 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
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
On Nov 13, 2004, at 6:20 PM, Thomas Hallgren wrote: > "Question about rename" on users@subversion.tigris.org > news://news.gmane.org:119/cmsqci$s9q$1@sea.gmane.org 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" > dev@subversion.tigris.org > news://news.gmane.org:119/419379F3.5070302@ftml.net 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 mademy 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
twp@castle.fastmail.fm (Travis P) wrote in message news:<F54111AA-35EB-11D9-B14F-003065F9DAF8@castle.fastmail.fm>... > > "Misinforming the user on rename with local changes" > > dev@subversion.tigris.org > > news://news.gmane.org:119/419379F3.5070302@ftml.net > > 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.
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