Thread: SCMS question
Are there any plans to move to another SCMS in the future? I am curious, I guess. wt -- Warren Turkal (w00t)
Warren Turkal <wt@penguintechs.org> writes:
> Are there any plans to move to another SCMS in the future?
Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify the pain
of converting.
regards, tom lane
On Thursday 22 February 2007 00:05, Tom Lane wrote: > Not particularly. We keep hearing from various advocates that > $foo-is-better-than-CVS, but the preferred value of $foo changes with > amazing frequency, and none of the arguments seem to justify the pain > of converting. Some of the other options just seem to have much nicer user interfaces. I was playing with Bacula and they just changed to Subversion. It really is much nicer than the CVS they used to use. Git seems interesting as well. I guess Subversion and git are the two big ones right now. What would you look for if you were to check out new SCMSes? Would you want distributed like Git or centralized like CVS/Subversion? wt -- Warren Turkal (w00t)
Warren Turkal <wt@penguintechs.org> writes:
> On Thursday 22 February 2007 00:05, Tom Lane wrote:
>> Not particularly. We keep hearing from various advocates that
>> $foo-is-better-than-CVS, but the preferred value of $foo changes with
>> amazing frequency, and none of the arguments seem to justify the pain
>> of converting.
> Some of the other options just seem to have much nicer user interfaces. I was
> playing with Bacula and they just changed to Subversion. It really is much
> nicer than the CVS they used to use. Git seems interesting as well. I guess
> Subversion and git are the two big ones right now. What would you look for if
> you were to check out new SCMSes? Would you want distributed like Git or
> centralized like CVS/Subversion?
I think you just made my point for me.
regards, tom lane
On Thursday 22 February 2007 00:42, you wrote: > I think you just made my point for me. I wasn't trying to convince so much as get an opinion. wt -- Warren Turkal (w00t)
Warren Turkal <wt@penguintechs.org> writes:
> On Thursday 22 February 2007 00:42, you wrote:
>> I think you just made my point for me.
> I wasn't trying to convince so much as get an opinion.
Well, sure, it's all opinion ;-). But the overall costs of changing
SCMS are pretty enormous IMHO. We're not going to do it just to find
out if the grass might be greener on the other side of the fence.
If you'd like to see it happen then you need to make some convincing
arguments ... starting with recommending one specific SCMS that we
should change to. If you haven't got a clear and defensible opinion
on that, then you've already lost my interest.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Warren Turkal <wt@penguintechs.org> writes: >> On Thursday 22 February 2007 00:05, Tom Lane wrote: >>> Not particularly. We keep hearing from various advocates that >>> $foo-is-better-than-CVS, but the preferred value of $foo changes with >>> amazing frequency, and none of the arguments seem to justify the pain >>> of converting. > >> Some of the other options just seem to have much nicer user interfaces. I was >> playing with Bacula and they just changed to Subversion. It really is much >> nicer than the CVS they used to use. Git seems interesting as well. I guess >> Subversion and git are the two big ones right now. What would you look for if >> you were to check out new SCMSes? Would you want distributed like Git or >> centralized like CVS/Subversion? > > I think you just made my point for me. Not really. That's not a "preferred value of $foo changing" so much as different styles of systems. If we want to minimize the pain of changing and keep the same mode of operation Subversion is definitely the right choice. Its goal was to provide the same operational model as CVS and fix the implementation and architectural problems. There isn't really any other mature SCM system in that style and I've heard nothing but satisfaction from its users. It has definitely taken over CVS's top spot in free software mindshare. If we wanted to go to a whole new way of working using a decentralized system which might fit better with our system of submitting patches then one of those other systems like GIT might be better. While I think our system of working independently and submitting patches actually fits GIT better, if we're so conservative that we're still on CVS despite its problems I suspect we're better off not trying to change operational models at this point. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
> If we want to minimize the pain of changing and keep the same mode of
> operation Subversion is definitely the right choice. Its goal was to provide
> the same operational model as CVS and fix the implementation and architectural
> problems.
Erm ... but this is not an argument in favor of changing.
AFAIR the only real disadvantage of CVS that we've run up against is
that it's hard to shuffle files around to different directories without
losing their change history (or more accurately, making the history
harder to find). Now that is a pretty considerable annoyance on some
days, but it's not sufficient reason to change to something else.
I have no doubt that every other SCMS has annoyances of its own.
> ... if we're so conservative that we're still on CVS
> despite its problems I suspect we're better off not trying to change
> operational models at this point.
Conservatism is kind of inherent in our problem domain, no? I mean,
you might have great arguments why XYZ is the best operating system
since sliced bread and everyone should migrate to it immediately, and
you might even be right --- but you'd be foolish to expect quick uptake
by the average DBA. There is great value in being familiar with one's
tools.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> If we want to minimize the pain of changing and keep the same mode of >> operation Subversion is definitely the right choice. Its goal was to provide >> the same operational model as CVS and fix the implementation and architectural >> problems. > > Erm ... but this is not an argument in favor of changing. > > AFAIR the only real disadvantage of CVS that we've run up against is > that it's hard to shuffle files around to different directories without > losing their change history (or more accurately, making the history > harder to find). Now that is a pretty considerable annoyance on some > days, but it's not sufficient reason to change to something else. > I have no doubt that every other SCMS has annoyances of its own. Oh we have tons of problems with CVS, it's just that we've worked around them for so long we've forgotten. Why are side projects like bitmapped indexes and the variable varlena stuff sitting on people's personal hard drives instead of in a branch of the main tree? It makes it awfully hard for developers to collaborate if they have to mail patches back and forth, merging conflicts manually and constantly negotiate what version of postgres the patches are against. Why are so few people committers? The normal work-flow on other projects is that you want any substantial changes in the revision control system as soon as possible so other people can see and work with them and use the revision control tools to manage them. The review process can either back them out or keep the production code on a separate branch and merge in the changes when they're approved. The answer to both questions is because CVS limitations make it hard to do better. There are no access control mechanisms and creating and managing branches is awkward and easy to get wrong. Mailing around patches basically limits us to one-person projects that can be reviewed by a single committer in a single sitting. Any larger and the people involved have no tools to coordinate or the committer has to deal with code drift in the main tree during the time he's reviewing the patch. [on a related note, is something wrong with my cvs rsync tree or is configure in the CVS repository? It's causing my patches to bloat considerably since I added one line to configure.in] > Conservatism is kind of inherent in our problem domain, no? I mean, > you might have great arguments why XYZ is the best operating system > since sliced bread and everyone should migrate to it immediately, and > you might even be right --- but you'd be foolish to expect quick uptake > by the average DBA. There is great value in being familiar with one's > tools. It's also why we have so many posters asking whether it's really necessary for them to upgrade from 7.0 which is working fine for them. Transaction wrap-around only happens once in a blue moon. And the weekly outages for vacuum fulls are scheduled and approved by management so we don't have to care about them any more. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote: > [on a related note, is something wrong with my cvs rsync tree or is > configure in the CVS repository? It's causing my patches to bloat > considerably since I added one line to configure.in] cat CVS/Entries -- Peter Eisentraut http://developer.postgresql.org/~petere/
"Peter Eisentraut" <peter_e@gmx.net> writes: > Gregory Stark wrote: >> [on a related note, is something wrong with my cvs rsync tree or is >> configure in the CVS repository? It's causing my patches to bloat >> considerably since I added one line to configure.in] > > cat CVS/Entries $ cat CVS/Entries D/config//// D/contrib//// D/doc//// D/src//// /configure.in/1.501/Wed Feb 14 11:43:15 2007// /COPYRIGHT/1.13/Thu Feb 15 14:31:14 2007// /GNUmakefile.in/1.46/Thu Feb 15 14:31:14 2007// /Makefile/1.13/Thu Feb 15 14:31:14 2007// /README/1.32/Thu Feb 15 14:31:14 2007// /README.CVS/1.3/Thu Feb 15 14:31:14 2007// /aclocal.m4/1.18/Thu Feb 15 14:31:14 2007// /configure/1.534/Wed Feb 7 00:28:54 2007// -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Thu, 22 Feb 2007, Tom Lane wrote: > Gregory Stark <stark@enterprisedb.com> writes: > > If we want to minimize the pain of changing and keep the same mode of > > operation Subversion is definitely the right choice. Its goal was to provide > > the same operational model as CVS and fix the implementation and architectural > > problems. > > Erm ... but this is not an argument in favor of changing. > > AFAIR the only real disadvantage of CVS that we've run up against is > that it's hard to shuffle files around to different directories without > losing their change history (or more accurately, making the history > harder to find). Now that is a pretty considerable annoyance on some > days, but it's not sufficient reason to change to something else. > I have no doubt that every other SCMS has annoyances of its own. It's not a problem for the project but I personally experience pain with CVS. I often want to take a bunch of commits and merge them into seperate trees (like Greenplum DB or my private bitmap index tree). This is a lot easier with the patch set based SCMs like darcs/monotone/git/etc. Just my thoughts. Gavin
Tom Lane wrote: > Gregory Stark <stark@enterprisedb.com> writes: > >> If we want to minimize the pain of changing and keep the same mode of >> operation Subversion is definitely the right choice. Its goal was to provide >> the same operational model as CVS and fix the implementation and architectural >> problems. >> > > Erm ... but this is not an argument in favor of changing. > > AFAIR the only real disadvantage of CVS that we've run up against is > that it's hard to shuffle files around to different directories without > losing their change history (or more accurately, making the history > harder to find). Now that is a pretty considerable annoyance on some > days, but it's not sufficient reason to change to something else. > I have no doubt that every other SCMS has annoyances of its own. > > Oh, goody! My favourite non-productive debate! :-) I work daily with SVN, and it certainly has some of the CVS pain points fixed, plus one or two nice gadgets. It's annoyed me a couple of times too, although I can't remember exactly how. Let me throw another couple of data points into the mix. 1. The buildfarm is very heavily dependent on CVS, and any change to anything else will be quite painful. There is no guarantee that all the members even have SVN installed, let alone anything else. And someone would have to code and test significant client changes. That said, a lot of the tortuous logic could be removed - change detection would almost just resolve to comparing two tree numbers with SVN, for example. 2. Many people (and some buildfarm members) operate against mirrors of the main repo which are created with rsync or CVSup. I am not aware of any way to do the equivalent with SVN - any info would be gratefully received. Of course, SVN is better at disconnected operation than CVS, so it might be a non-issue for many. Even so, it might be a pity to have to forego the facility. I have no doubt we'll change someday to something better. I don't know what it is and I don't think we need to be in any hurry. This space is still very fluid. cheers andrew
Hi, Andrew Dunstan wrote: > 1. The buildfarm is very heavily dependent on CVS, and any change to > anything else will be quite painful. There is no guarantee that all the > members even have SVN installed, But you can guarantee they have CVS or even cvsup installed? That seems dubious to me. > let alone anything else. And someone > would have to code and test significant client changes. That said, a lot > of the tortuous logic could be removed - change detection would almost > just resolve to comparing two tree numbers with SVN, for example. ..and a *real* VCS (as in monotone :-) ) would provide not only that, but give you correctness guarantees, built in certification of revisions (i.e. each buildfarm member could issue a cert on successful testing) and lightweight branches, so you could much easier test experimental patches of different authors. Just to name a few additional advantages. > 2. Many people (and some buildfarm members) operate against mirrors of > the main repo which are created with rsync or CVSup. I am not aware of > any way to do the equivalent with SVN - any info would be gratefully > received. You might want to have a look at svk. It can do exactly that. And the Blog of Thomas explains how, see [1]. > Of course, SVN is better at disconnected operation than CVS, Really? I've dropped subversion exactly because it sucks big time when disconnected. But again, I'm probably not comparing against CVS... > I have no doubt we'll change someday to something better. I don't know > what it is and I don't think we need to be in any hurry. This space is > still very fluid. Yup. Good to hear you see it that way. As I understand, you have good reasons to be still using CVS, but are open to good suggestions. That's a very good thing, but easily slips by when reading all the critics and pro-CVS statements. ;-) Regards Markus [1]: Remote Backup Of A Subversion Repository http://moelhave.dk/2006/07/remote-mirroring-a-subversion-svn-repository/
Markus Schiltknecht wrote: > Hi, > > Andrew Dunstan wrote: >> 1. The buildfarm is very heavily dependent on CVS, and any change to >> anything else will be quite painful. There is no guarantee that all >> the members even have SVN installed, > > But you can guarantee they have CVS or even cvsup installed? That seems > dubious to me. getting CVS on a box is still way easier than SVN (I don't want event talk about more esoteric ones) especially on older and/or special platforms. As someone who operates a large number of buildfarm members switching to something else would put a large burden(both in terms of installation and configuration changes/upgrades of the buildfarm client) on me for no appearent gain. Beside that - are all of the currently supported Platforms officially supported by the proposed SCMSes ? > >> let alone anything else. And someone would have to code and test >> significant client changes. That said, a lot of the tortuous logic >> could be removed - change detection would almost just resolve to >> comparing two tree numbers with SVN, for example. > > ..and a *real* VCS (as in monotone :-) ) would provide not only that, > but give you correctness guarantees, built in certification of revisions > (i.e. each buildfarm member could issue a cert on successful testing) > and lightweight branches, so you could much easier test experimental > patches of different authors. Just to name a few additional advantages. most of the issues with CVS in that regard have already been worked around (and are therefore "solved"). But I agree that for developers especially those that are doing large patches over a long period of time might gain something from another SCMS, but it is not really clear what that SCMS should be or if it warrants the imho enormous switching costs (and the potential disruption in development until that switch is done whichmight take days if not weeks). Stefan
Hi, [ I've CCed the monotone-devel list, as I'm sure those people are interested, too. ] Stefan Kaltenbrunner wrote: > Beside that - are all of the currently supported Platforms officially > supported by the proposed SCMSes ? I can only speak for monotone. We have (had) buildbots for x86 (linux, netbsd, freebsd, win32), amd64 (linux), ppc (osx) and one sparc (osol). So far all gcc compiled, AFAIK. We are very interested in increasing portability of monotone. If you could give me (or other monotone devels) ssh access to some of the more obscure boxes, that would help a lot. Please contact me privately. > most of the issues with CVS in that regard have already been worked > around (and are therefore "solved"). Huh? How do you guarantee the correctness of a local checkout? At best, you can check an md5 sum of a tar archive, but CVS itself does almost no integrity checking. Does the buildfarm code check somehow? Against what? (Note that we've already had quite some disk failures uncovered by monotone, which does extensive integrity checking. But I'm sure database people know how important that is, don't you?) Or quickly test experimental patches? Is that solved? Or merging between branches, to add another major annoyance of CVS (and subversion, for that matter). I currently fetch the whole PostgreSQL repository via cvsup and then import it into monotone to be able to do serious work. Of course that's possible, and you can work around all the other limitations of CVS somehow, but it's annoying. > But I agree that for developers especially those that are doing large > patches over a long period of time might gain something from another > SCMS, but it is not really clear what that SCMS should be or if it > warrants the imho enormous switching costs (and the potential disruption > in development until that switch is done which might take days if not > weeks). I certainly agree that switching to another VCS is a major undertaking. And I'm working on easing migration to monotone. And I'll quite certainly try again to convince you again, *at some point in the future*. I would not vote for switching the PostgreSQL repository to monotone, yet. (As if I had a vote...;-) ) Regards Markus
Markus Schiltknecht wrote: > Hi, > > Andrew Dunstan wrote: >> 1. The buildfarm is very heavily dependent on CVS, and any change to >> anything else will be quite painful. There is no guarantee that all >> the members even have SVN installed, > > But you can guarantee they have CVS or even cvsup installed? That > seems dubious to me. CVSup is not required, and is absent from most existing clients. I don't use it any more since the Fedora project stopped supporting it. Buildfarm was designed to be able to run anywhere that a build from our repo could run, without requiring anything extra - I have even tried to keep to a minimum the perl modules required. The point you are missing is that, while we know existing buildfarm members all have CVS installed, we don't know that they have SVN or whatever, and requiring them to install it will involve significant distributed pain. It will also involve some considerable localised pain (probably on my part) in rewriting the client. Right now I'm thinking it might make some sense to future-proof buildfarm by creating some sort of snapshot server. OTOH, if we avoid use of whatever SCM system that the project uses, we aren't testing that part of the process. > >> let alone anything else. And someone would have to code and test >> significant client changes. That said, a lot of the tortuous logic >> could be removed - change detection would almost just resolve to >> comparing two tree numbers with SVN, for example. > > ..and a *real* VCS (as in monotone :-) ) would provide not only that, > but give you correctness guarantees, built in certification of > revisions (i.e. each buildfarm member could issue a cert on successful > testing) and lightweight branches, so you could much easier test > experimental patches of different authors. Just to name a few > additional advantages. You're making Tom's point again :-) >> Of course, SVN is better at disconnected operation than CVS, > > Really? I've dropped subversion exactly because it sucks big time when > disconnected. But again, I'm probably not comparing against CVS... IIRC you don't need to be connected to the repo to run "svn diff", whereas you do to run "cvs diff". > >> I have no doubt we'll change someday to something better. I don't >> know what it is and I don't think we need to be in any hurry. This >> space is still very fluid. > > Yup. Good to hear you see it that way. As I understand, you have good > reasons to be still using CVS, but are open to good suggestions. > That's a very good thing, but easily slips by when reading all the > critics and pro-CVS statements. ;-) We know the warts. If this were a green fields project there is no doubt we would not use CVS. But many proponents of other systems ignore the downside of changing. One thing I want to know is that whatever we change to will still be there, maintained and in widespread use, many years down the track. So far I am not sure about that for any possible replacement, with the possible exception of SVN. cheers andrew
Hi,
Andrew Dunstan wrote:
> CVSup is not required, and is absent from most existing clients. I don't
> use it any more since the Fedora project stopped supporting it.
..which is quite understandable, concerning the PITA compiling modula-3
gives you (or at least has given me, it still hurts).
> The point you are missing is that, while we know existing buildfarm
> members all have CVS installed, we don't know that they have SVN or
> whatever, and requiring them to install it will involve significant
> distributed pain.
Okay, I certainly agree that CVS is much more wide spread and available
than most (if not all) other VCSes. Let's change that ;-)
> It will also involve some considerable localised pain
> (probably on my part) in rewriting the client. Right now I'm thinking it
> might make some sense to future-proof buildfarm by creating some sort of
> snapshot server. OTOH, if we avoid use of whatever SCM system that the
> project uses, we aren't testing that part of the process.
Did I mention that monotone is a very good snapshot server? *duck*
You probably don't want to reinvent the weel, as 'snapshot serving' is
exactly what a VCS should do (among other things).
> You're making Tom's point again :-)
Yeah, sorry, couldn't resist :-)
> IIRC you don't need to be connected to the repo to run "svn diff",
> whereas you do to run "cvs diff".
Yes, in the simplest case of comparing against the immediate successor
revision. But certainly not for: svn diff -r${FURTHER_IN_THE_PAST}, as
subversion does not have that data available (nor does CVS, for that
matter).
> We know the warts. If this were a green fields project there is no doubt
> we would not use CVS. But many proponents of other systems ignore the
> downside of changing.
Well, I guess many advocates for other VCSes (like myself) simply don't
particularly like to talk about the downsides... But they are probably
more aware of them than most other people.
> One thing I want to know is that whatever we change to will still be
> there, maintained and in widespread use, many years down the track. So
> far I am not sure about that for any possible replacement, with the
> possible exception of SVN.
That's certainly a valid concern, too. Probably *the* one where monotone
is weaker compared to git and mercurial. :-( We are working on that
issue, though.
Regards
Markus
Hello Richard, you should probably have read the thread on the PostgreSQL -hackers mailing list I've linked to... at least you didn't make Tom's point ;-) Richard Levitte - VMS Whacker wrote: > 1. Do you want to stay with CVS or do you want to move to something > else? Most PostgreSQL developers currently want to stay with CVS. Only some desperate souls including myself are fiddling with other VCSes. > 3. What would you want a replacement to be able to do? That's being debated, with many voices saying: CVS (plus our own hackery) provides all we need. (And be warned again: as soon as you point out an advantage of your favourite VCS, you're making Tom's point. ;-) ) > So far, I'm getting the sense that there are a lot of opinions on what > replacement system to use, a bit carelessly before having answered the > above questions thoroughly. How did you get that impression? I'm currently *using* monotone for Postgres-R development, doing cvs_import and propagating to my branch. And I know others did the same already, too. Regards Markus
Markus Schiltknecht wrote: > > Richard Levitte - VMS Whacker wrote: >> 1. Do you want to stay with CVS or do you want to move to something >> else? > > Most PostgreSQL developers currently want to stay with CVS. Only some > desperate souls including myself are fiddling with other VCSes. I really don't think this is a correct characterisation. What is true, I think, is that many remain to be convinced that the benefits of any proposed change outweigh the likely pain, and I suspect many are also uncertain about what's happening in the SCM space and prefer to wait until the dust settles some. It's also fair to say that this is a subject about which we usually get much more noise from partisans of other SCM systems than from the relatively small number of people who actually have to maintain the postgresql code. (As Tom has pointed out, our biggest pain point is the occasional wish to move things across directories.) cheers andrew
Andrew Dunstan wrote:
> Markus Schiltknecht wrote:
>>
>> Richard Levitte - VMS Whacker wrote:
>>> 1. Do you want to stay with CVS or do you want to move to something
>>> else?
>>
>> Most PostgreSQL developers currently want to stay with CVS. Only some
>> desperate souls including myself are fiddling with other VCSes.
>
>
> I really don't think this is a correct characterisation. What is true, I
> think, is that many remain to be convinced that the benefits of any
> proposed change outweigh the likely pain, and I suspect many are also
> uncertain about what's happening in the SCM space and prefer to wait
> until the dust settles some.
I believe that is much more accurate. The reality is, switching to
something else will be painful. I would prefer not to be on CVS as well
but it would take a lot of work and cvs does what we need it to.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Thursday 22 February 2007 05:26, Andrew Dunstan wrote: > 2. Many people (and some buildfarm members) operate against mirrors of > the main repo which are created with rsync or CVSup. I am not aware of > any way to do the equivalent with SVN - any info would be gratefully > received. Of course, SVN is better at disconnected operation than CVS, > so it might be a non-issue for many. Even so, it might be a pity to have > to forego the facility. Check out svnsync for SVN. It's part of a normal SVN installation. With git, a checkout brings the whole repository anyway, I think. wt -- Warren Turkal (w00t)
"Andrew Dunstan" <andrew@dunslane.net> writes: > 2. Many people (and some buildfarm members) operate against mirrors of the main > repo which are created with rsync or CVSup. I am not aware of any way to do the > equivalent with SVN - any info would be gratefully received. Of course, SVN is > better at disconnected operation than CVS, so it might be a non-issue for many. > Even so, it might be a pity to have to forego the facility. Well SVN basically works by having that mirror all the time. That kind of sucks for people with many checkouts since it takes more disk space but it provides the same benefits of having a local mirror of the CVS repository which is really just working around the problems with CVS. The general point about the build farms is a strong argument in favor of SVN over the new-fangled revision control systems. It would involve the least change in the operational model and the main build farm maintainer is familiar with it... It's also the easiest to get ahold of. Easier I would say than CVS which you have to download some bug fixes from various unofficial sites to get a good working version of. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Andrew Dunstan wrote: > It's also fair to say that this is a subject about which we usually get > much more noise from partisans of other SCM systems than from the > relatively small number of people who actually have to maintain the > postgresql code. (As Tom has pointed out, our biggest pain point is the > occasional wish to move things across directories.) There are more features we are missing -- we just don't know about them :-) For example, currently if I have a patch and somebody reviews it and opines that I have to change foo to bar; then I resubmit the patch. How do they find out whether I actually changed foo to bar? Currently there are two alternatives: 1. trust that I did it 2. review the whole patch again With a distributed SCM, I could just patch the code and commit a new revision in my branch to just change foo to bar, and then the reviewer can check that I truly did what he wanted. Another easy thing to do is to track the current HEAD in a branch of mine. Keeping patches up to date in parallel with other developments is easier. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Warren Turkal wrote: > On Thursday 22 February 2007 05:26, Andrew Dunstan wrote: > >> 2. Many people (and some buildfarm members) operate against mirrors of >> the main repo which are created with rsync or CVSup. I am not aware of >> any way to do the equivalent with SVN - any info would be gratefully >> received. Of course, SVN is better at disconnected operation than CVS, >> so it might be a non-issue for many. Even so, it might be a pity to have >> to forego the facility. >> > > Check out svnsync for SVN. It's part of a normal SVN installation. > > Nifty. Thanks. andrew
Andrew Dunstan wrote: > Warren Turkal wrote: >> On Thursday 22 February 2007 05:26, Andrew Dunstan wrote: >> >>> 2. Many people (and some buildfarm members) operate against mirrors of >>> the main repo which are created with rsync or CVSup. I am not aware of >>> any way to do the equivalent with SVN - Well you could just use rsync with svn ;) >> any info would be gratefully >>> received. Of course, SVN is better at disconnected operation than CVS, >>> so it might be a non-issue for many. Even so, it might be a pity to have >>> to forego the facility. >>> >> >> Check out svnsync for SVN. It's part of a normal SVN installation. >> That is cool, I didn't know about that. Other items I find interesting about SVN: 1. It has an api that can be written to, that may or may not be helpful to buildfarm. 2. It has mindshare. I know that isn't a big deal to a lot of people here, but the it is becoming the new cvs. There are others of course (like monotone) but most projects I know are moving from cvs to svn or starting with svn. Joshua D. Drake >> > > Nifty. > > Thanks. > > andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
Markus Schiltknecht wrote: > Most PostgreSQL developers currently want to stay with CVS. Only some > desperate souls including myself are fiddling with other VCSes. I think if you took a head count, a majority of developers would probably want to switch, but I doubt that there would be a consensus on what to. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Gregory Stark wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > [...] > It's also the easiest to get ahold of. Easier I would say than CVS which you > have to download some bug fixes from various unofficial sites to get a good > working version of. just to mention it - the openbsd gyus are working on a BSD licenced CVS rewrite too (and i believe they strike for full compat first and improve on the main week points later on). some information about that effort is available here: http://www.opencvs.org/. Stefan
Gregory Stark wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > > > 2. Many people (and some buildfarm members) operate against mirrors of the main > > repo which are created with rsync or CVSup. I am not aware of any way to do the > > equivalent with SVN - any info would be gratefully received. Of course, SVN is > > better at disconnected operation than CVS, so it might be a non-issue for many. > > Even so, it might be a pity to have to forego the facility. > > Well SVN basically works by having that mirror all the time. That kind of > sucks for people with many checkouts since it takes more disk space but it > provides the same benefits of having a local mirror of the CVS repository > which is really just working around the problems with CVS. > > The general point about the build farms is a strong argument in favor of SVN > over the new-fangled revision control systems. It would involve the least > change in the operational model and the main build farm maintainer is familiar > with it... Nonsense. Getting a checkout is almost as easy in Monotone as it is in CVS or subversion. You just get an initial copy of the database and then get all your checkouts from there. In SVN there's this strange notion of keeping the latest revision within the checked out copy: if you have more than one working copy, you get the same stuff multiple times. If you "grep" the whole source tree you get a lot of extraneous files in the grep result, which you then have to "grep -v" out, which is annoying. In Monotone the database is separate from the working copy, and from one database you can get as many working copies as you want. You don't need to mirror the repository, because you _have_ the repository. (I guess another way to put it is that mirroring the repository is part of everyday operation). We use SVN internally in Command Prompt, and I will change to anything else any day :-) One thing that Monotone doesn't do to which we are used to, is $Id$-style keyword expansion. The only other problem I see currently is the long time to get an initial pull. > It's also the easiest to get ahold of. Easier I would say than CVS which you > have to download some bug fixes from various unofficial sites to get a good > working version of. Sure, anything is better than CVS :-) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
andrew@dunslane.net (Andrew Dunstan) writes: > Tom has pointed out, our biggest pain point is > the occasional wish to move things across directories. That's the biggest pain that people are normally aware of. There are things that people don't even bother to try to do with CVS because they are so impossible as to be stupid ideas. Notably, CVS, being an inherently centralized system, doesn't support the notion of having a secondary repository tracking projects that haven't been able to be committed into the central project. -- (reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc")) http://linuxfinances.info/info/finances.html Rules of the Evil Overlord #189. "I will never tell the hero "Yes I was the one who did it, but you'll never be able to prove it to that incompetent old fool." Chances are, that incompetent old fool is standing behind the curtain." <http://www.eviloverlord.com/>
In message <45DDCE5C.9000107@commandprompt.com> on Thu, 22 Feb 2007 09:09:48 -0800, "Joshua D. Drake" <jd@commandprompt.com>said: jd> I believe that is much more accurate. The reality is, switching to jd> something else will be painful. I would prefer not to be on CVS as jd> well but it would take a lot of work and cvs does what we need it jd> to. I can only tell you my own story, and that's a story of being sick and damn (oh, I've a much stronger word, but I'm too polite to use it here) tired of CVS, especially having had to deal with it's absolute lack of merging capacity. It's taken trying a number of other SCMs, which were all a PITA, until I found monotone, before I decided I had found a worthy replacement. To each his or her own, I say, and as you say, chaging (or "moving on") takes some amount of effort, and you will not do it, as a group, before more or less all (especially any core group) thinks it's worth more than staying with the current system. Cheers, Richard -- Richard Levitte richard@levitte.org http://richard.levitte.org/ "When I became a man I put away childish things, includingthe fear of childishness and the desire to be very grown up." -- C.S. Lewis
On Thu, Feb 22, 2007 at 03:13:49PM +0100, Markus Schiltknecht wrote: > one sparc (osol). So far all gcc compiled, AFAIK. I think, that buildbot was gcc on solaris9/sparc. I care for support of monotone built with sunpro on solaris10 (and opensolaris) on x86 and sparc (but no buildbot for those). there was once some work on msvc support, but I have no idea what happened to that. patrick georgi
If I may, I'll add a few words to this discussion: Basically, I'm seeing that three things need to be decided upon: 1. Do you want to stay with CVS or do you want to move to something else? 2. If you want to move, when? Is now a goodtime, or is it better to look at it another time. This may be a question of what people you have who'd do thejob, what kind of time they have for the moment and so on. 3. What would you want a replacement to be able to do? When those questions are answered and people are behind it, then it's time to look at the different systems and see what' the best match to your desires. So far, I'm getting the sense that there are a lot of opinions on what replacement system to use, a bit carelessly before having answered the above questions thoroughly. HTH. Cheers, Richard -- Richard Levitte richard@levitte.org http://richard.levitte.org/ "When I became a man I put away childish things, includingthe fear of childishness and the desire to be very grown up." -- C.S. Lewis
In message <45DDC702.4060205@bluegap.ch> on Thu, 22 Feb 2007 17:38:26 +0100, Markus Schiltknecht <markus@bluegap.ch> said: markus> > So far, I'm getting the sense that there are a lot of markus> > opinions on what replacement system to use, a bit carelessly markus> > before having answered the above questions thoroughly. markus> markus> How did you get that impression? You said it yourself: Most PostgreSQL developers currently want to stay with CVS. Unless there's a majority that wants to move on, I doubt there will be a move. In the end, it has to be a group effort, or it will simply not happen. Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte richard@levitte.org http://richard.levitte.org/ "When I became a man I put away childish things, includingthe fear of childishness and the desire to be very grown up." -- C.S. Lewis
On Thursday 22 February 2007 11:00, Joshua D. Drake wrote: > 1. It has an api that can be written to, that may or may not be helpful > to buildfarm. > > 2. It has mindshare. I know that isn't a big deal to a lot of people > here, but the it is becoming the new cvs. There are others of course > (like monotone) but most projects I know are moving from cvs to svn or > starting with svn. Git is also pretty cool, too. You can even present a CVS interface on a git repository. That might address the build farm issue. wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Thursday 22 February 2007 11:00, Joshua D. Drake wrote: > > 1. It has an api that can be written to, that may or may not be helpful > > to buildfarm. > > > > 2. It has mindshare. I know that isn't a big deal to a lot of people > > here, but the it is becoming the new cvs. There are others of course > > (like monotone) but most projects I know are moving from cvs to svn or > > starting with svn. > > Git is also pretty cool, too. You can even present a CVS interface on a git > repository. That might address the build farm issue. But it wasn't portable, last time I checked. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Warren Turkal wrote: > >> On Thursday 22 February 2007 11:00, Joshua D. Drake wrote: >> >>> 1. It has an api that can be written to, that may or may not be helpful >>> to buildfarm. >>> >>> 2. It has mindshare. I know that isn't a big deal to a lot of people >>> here, but the it is becoming the new cvs. There are others of course >>> (like monotone) but most projects I know are moving from cvs to svn or >>> starting with svn. >>> >> Git is also pretty cool, too. You can even present a CVS interface on a git >> repository. That might address the build farm issue. >> > > But it wasn't portable, last time I checked. > > Besides that, the whole idea is that buildfarm should mimic as exactly as possible how we checkout and build by hand. cheers andrew
On Thursday 22 February 2007 20:39, Alvaro Herrera wrote: > > Git is also pretty cool, too. You can even present a CVS interface on a > > git repository. That might address the build farm issue. > > But it wasn't portable, last time I checked. Git is in the FreeBSD ports. The cvs gateway server comes with it AFAIK. wt -- Warren Turkal (w00t)
Gregory Stark <stark@enterprisedb.com> writes:
> [much snipped]
> Why are so few people committers?
> ...
> The answer to both questions is because CVS limitations make it hard to do
> better.
Uh, no. The reason there are so few committers is that there are so few
people qualified not to break things.
If we had a community with hundreds of people with commit access, very
possibly we'd be feeling the need of a better SCM system. But right
now, CVS is not the bottleneck, and I don't see that we'd get a payback
for the pain of changing to something else.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> [much snipped] >> Why are so few people committers? >> ... >> The answer to both questions is because CVS limitations make it hard to do >> better. > > Uh, no. The reason there are so few committers is that there are so few > people qualified not to break things. Not to break the codebase? Or not to break the archive? It's only due to CVS's awkwardness that the latter is a concern at all. > If we had a community with hundreds of people with commit access, very > possibly we'd be feeling the need of a better SCM system. But right > now, CVS is not the bottleneck, and I don't see that we'd get a payback > for the pain of changing to something else. I'm not suggesting changing the number of people who can commit code to HEAD. But getting work into the revision control system sooner, before it's ready to be merged into HEAD. Right now we're giving up most of the advantages revision control systems exist for. We're using CVS as a glorified archival system. You're still merging patches and reviewing patches by hand, without any of the tools to, for example, view incremental changes in the branch, view the logs of the branch, merge the branch into the code automatically taking into account the known common ancestor. Instead of receiving a 20k patch without any tools to work with it you would be given a branch name and be able to view and merge it into the main branch using the tools. Moreover work on things like bitmapped indexes that other people want to help on is hampered by this need to be mailing around patches. If two or three people submit changes (based possibly on different old versions of the patch) the main developer has to merge them into his version of the patch by hand and mail out a new patch. The whole point of a revision control system is to provide tools to make that easier. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Hi, Richard Levitte - VMS Whacker wrote: > In message <45DDC702.4060205@bluegap.ch> on Thu, 22 Feb 2007 17:38:26 +0100, Markus Schiltknecht <markus@bluegap.ch> said: > > markus> > So far, I'm getting the sense that there are a lot of > markus> > opinions on what replacement system to use, a bit carelessly > markus> > before having answered the above questions thoroughly. > markus> > markus> How did you get that impression? > > You said it yourself: Most PostgreSQL developers currently want to > stay with CVS. Uh, yah. But I was refering to the "lots of opinions on what replacement system to use". This has not much to do with the want or need (for lack of a better alternative) to stay with CVS, IMO. > Unless there's a majority that wants to move on, I doubt there will be > a move. In the end, it has to be a group effort, or it will simply > not happen. I absolutely agree. And I'm quite sure most PostgreSQL developers also know that, thus I don't see much point in warning them - they are resistant enough ;-) As you might have noticed, I myself don't consider monotone ready for use by the PostgreSQL project, yet. And I've never advocated for switching *now*. I only made Tom's point... Regards Markus
On Wednesday 21 February 2007 21:23, Warren Turkal wrote: > Are there any plans to move to another SCMS in the future? I am curious, I > guess. Speaking of which...Are there any plans to upgrade the CVS server to the latest version? wt -- Warren Turkal (w00t)
Hey, Anyone who followed the thread willing to list the mentioned requirements as well as the pro's and con's of the differnent options in the developer wiki [1]? I think this would help a lot in making a decision and it could be a lot of help for other OSS projects considering to switch. If you do not have an account with write access, just open an account on the wiki and email Greg to get your ACL's upgraded so you can write into the wiki. I can also try to work on this a bit over the weekend. regards, Lukas [1] http://developer.postgresql.org
Richard Levitte - VMS Whacker wrote: > In message <45DE9071.5020909@bluegap.ch> on Fri, 23 Feb 2007 07:57:53 +0100, Markus Schiltknecht <markus@bluegap.ch> said: > > markus> Uh, yah. But I was refering to the "lots of opinions on what > markus> replacement system to use". This has not much to do with the > markus> want or need (for lack of a better alternative) to stay with > markus> CVS, IMO. > > Oh, it's an academic discussion? Sorry, didn't catch that. It's only academic because Monotone is not ready. As soon as it is ready we will be pushing much harder. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
hendrik@topoi.pooq.com wrote: > On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote: > > Richard Levitte - VMS Whacker wrote: > > > In message <45DE9071.5020909@bluegap.ch> on Fri, 23 Feb 2007 07:57:53 +0100, Markus Schiltknecht <markus@bluegap.ch>said: > > > > > > markus> Uh, yah. But I was refering to the "lots of opinions on what > > > markus> replacement system to use". This has not much to do with the > > > markus> want or need (for lack of a better alternative) to stay with > > > markus> CVS, IMO. > > > > > > Oh, it's an academic discussion? Sorry, didn't catch that. > > > > It's only academic because Monotone is not ready. As soon as it is > > ready we will be pushing much harder. > > This invites the obvious question -- in which ways in monotone not > ready? Not that I'm trying to imply that monotone *is* ready, of > course. Time to get the initial pull is too long, mostly. Also, having the policy branch stuff will be good, if nothing else because it'll mean having 1.0 out, in turn meaning UI stability, etc. And getting Markus' work on the CVS import will be good too (I haven't tried converting Postgres' entire CVS repo in a while, and that certainly is a must). I don't think we're going to get a one-shot migration, so Cristof's work on CVS takeover would be really nice to have so that some of us can create an "alternative" repo and cater for those that will continue to use CVS for a while. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
richard@levitte.org (Richard Levitte - VMS Whacker) writes: > In message <45DDC702.4060205@bluegap.ch> on Thu, 22 Feb 2007 17:38:26 +0100, Markus Schiltknecht <markus@bluegap.ch> said: > > markus> > So far, I'm getting the sense that there are a lot of > markus> > opinions on what replacement system to use, a bit carelessly > markus> > before having answered the above questions thoroughly. > markus> > markus> How did you get that impression? > > You said it yourself: Most PostgreSQL developers currently want to > stay with CVS. I'm not certain that is, statistically, the case. > Unless there's a majority that wants to move on, I doubt there will be > a move. In the end, it has to be a group effort, or it will simply > not happen. The trouble is that there needs to be a sufficient plurality in favor of *a particular move onwards* in order for it to happen. Right now, what we see is: - Some that are fine with status quo - Some that are keen on Subversion - Others keen on Monotone - Others considering other options; Darcs, Git, Mercurial, Arch... There's no majority there, for sure. No plurality, either. There has been a "convulsion" of activity surrounding SCM in the last couple of years, and I think that the brief trouble that the Linux kernel had with Bitkeeper going away has been an *excellent* thing as it drew developers to work on the (long languishing) SCM problem. It looks as though there is a strong "plurality" of PostgreSQL developers that are waiting for some alternative to become dominant. I suspect THAT will never happen. I think instead, that we will see three or maybe four of the newer SCMs being jointly dominant. - Subversion has a clear body of happy-enough users for Subversion to continue. - Git, being the Linux kernel SCM, will continue unless some heretofore undiscovered fatal flaw bites it. - Mercurial seems to have enough user projects to be viable. (OpenSolaris, ALSA, Xen, ZFS for Linux are probably recognizable names...) It seems plausible that one of [Arch, Darcs, Monotone] would also survive. This contradicts the notion of there being any single dominant successor to CVS; if that were the case, that would make a migration clear. I think, instead, that we'll continue to see a multiplicity of choices, meaning that the best we can do is to eventually pick one. There isn't enough of a 'plurality' of support for any one SCM to allow that to take place now. -- (reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc")) http://linuxfinances.info/info/finances.html Rules of the Evil Overlord #189. "I will never tell the hero "Yes I was the one who did it, but you'll never be able to prove it to that incompetent old fool." Chances are, that incompetent old fool is standing behind the curtain." <http://www.eviloverlord.com/>
Warren Turkal wrote: > On Thursday 22 February 2007 20:39, Alvaro Herrera wrote: > > > Git is also pretty cool, too. You can even present a CVS interface on a > > > git repository. That might address the build farm issue. > > > > But it wasn't portable, last time I checked. > > Git is in the FreeBSD ports. The cvs gateway server comes with it AFAIK. Sorry, I mean Windows. We're taken pains to ensure Postgres runs on Windows, we're not going to abandon that platform now. And there's a lot of platforms on which we'd have to make sure Monotone also runs on. Our buildfarm currently has http://buildfarm.postgresql.org/cgi-bin/show_status.pl NetBSD OpenBSD FreeBSD Max OS X Tru64 5.0 (cc V6.1-011, on alpha) AIX 5.2 (on powerpc) Solaris 10 UnixWare 7.1.4 (cc 4.2, on "isa", whatever that is) Cygwin Native Windows: XP, 2000, 2003 Several flavors of Linux Probably all those that can run GCC will have no problem with Monotone. But what about the AIX, Tru64, Unixware entries? Do they even have C++ compilers? I don't think Git runs on all these. It's not on the buildfarm but HP-UX is also used. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Chris Browne wrote: > The trouble is that there needs to be a sufficient plurality in favor > of *a particular move onwards* in order for it to happen. > > Right now, what we see is: > > - Some that are fine with status quo > - Some that are keen on Subversion > - Others keen on Monotone > - Others considering other options; Darcs, Git, Mercurial, Arch... > > There's no majority there, for sure. No plurality, either. > > There has been a "convulsion" of activity surrounding SCM in the last > couple of years, and I think that the brief trouble that the Linux > kernel had with Bitkeeper going away has been an *excellent* thing as > it drew developers to work on the (long languishing) SCM problem. > > It looks as though there is a strong "plurality" of PostgreSQL > developers that are waiting for some alternative to become dominant. > I suspect THAT will never happen. > It probably _can_ never happen, because that would have to be a one-for-all solution, embracing both centric and distributed repositories, combining contradictionary goals. So the first question to answer is: Will PostgreSQL continue with a single repository (the project was managed very successfully this way for a long time), or try a distributed approach. IMHO facts would quote for a central repository, which would drastically reduce SCM candidates. Regards, Andreas
> Moreover work on things like bitmapped indexes that other people want to help
> on is hampered by this need to be mailing around patches. If two or three
> people submit changes (based possibly on different old versions of the patch)
> the main developer has to merge them into his version of the patch by hand and
> mail out a new patch. The whole point of a revision control system is to
> provide tools to make that easier.
O.k. everyone pay attention, I am about to agree with Greg! ;)
Greg are their tools to migrate CVS to monotone or whatever your
favorite is? The reason I ask is that I migrate the CVS to SVN every 4
hours I think it is and it isn't perfect.
You get weird messages in the logs that don't track right. Remember, we
have a very large repo.
Anyway, my point is, if we have those tools, why don't we do a
migration, have some peer review on the migration and actually make an
argument based on the results versus the theory?
I am happy to help with this any way I can, because I would love to see
CVS take a big diving leap off the backend of mysql into the truncated
data set of hell.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote: >> Moreover work on things like bitmapped indexes that other people want to help >> on is hampered by this need to be mailing around patches. If two or three >> people submit changes (based possibly on different old versions of the patch) >> the main developer has to merge them into his version of the patch by hand and >> mail out a new patch. The whole point of a revision control system is to >> provide tools to make that easier. >> > > O.k. everyone pay attention, I am about to agree with Greg! ;) > > Greg are their tools to migrate CVS to monotone or whatever your > favorite is? The reason I ask is that I migrate the CVS to SVN every 4 > hours I think it is and it isn't perfect. > Are you going to do trials for just Monotone, or will you include alternatives like, say, Mercurial (which seems to have quite a bit of traction, and should appeal to you as it's written in Python)? There is a generic conversion tool called Tailor that might help you: http://www.darcs.net/DarcsWiki/Tailor cheers andrew
On Fri, Feb 23, 2007 at 09:12:27AM -0500, Chris Browne wrote: > It looks as though there is a strong "plurality" of PostgreSQL > developers that are waiting for some alternative to become dominant. > I suspect THAT will never happen. Actually, I think that if one of the SCMs provides some kind of server interface that allows clients to keep using the CVS client if they want, they would get significant traction. If only because it allows people and existing tools to keep working while providing extra possibilities. IOW provide a nice upgrade path for the transition and a lot of the problems switching go away. Then again, it's probably nowhere near as easy as I make it sound :) Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Fri, Feb 23, 2007 at 08:32:34AM -0800, Joshua D. Drake wrote: > I am happy to help with this any way I can, because I would love to see > CVS take a big diving leap off the backend of mysql into the truncated > data set of hell. That quote made the whole argument coming up again worthwhile. :) -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Feb 23, 2007, at 11:24 , Andreas Pflug wrote: >> > It probably _can_ never happen, because that would have to be a > one-for-all solution, embracing both centric and distributed > repositories, combining contradictionary goals. So the first > question to > answer is: Will PostgreSQL continue with a single repository (the > project was managed very successfully this way for a long time), or > try > a distributed approach. IMHO facts would quote for a central > repository, > which would drastically reduce SCM candidates. Any distributed SCM can be inherently be used as a central repo. The project leaders would merely designate one place from whence builds are generated and developers would simply sync with the "central" repo. In fact, distributed SCMs fit the open source development model better because any failure of the "central" repo (crash, buy-out, sabotage, needing a project fork) cannot cause chaos: a new "central" repo is designated- essentially an instant failover. Cheers, M
Martijn van Oosterhout wrote:
> On Fri, Feb 23, 2007 at 09:12:27AM -0500, Chris Browne wrote:
>> It looks as though there is a strong "plurality" of PostgreSQL
>> developers that are waiting for some alternative to become dominant.
>> I suspect THAT will never happen.
Actually it has. The problem is different SCMS offer different things.
If you are looking for a CVS replacement, that replacement is SVN. I
don't think anyone can reasonably argue against that statement.
If you are looking for something that is not a CVS replacement, but
offers SCM and has different features (like mercurial) then I agree with
you.
Sincerely,
Joshua D. Drake
>
> Actually, I think that if one of the SCMs provides some kind of server
> interface that allows clients to keep using the CVS client if they
> want, they would get significant traction. If only because it allows
> people and existing tools to keep working while providing extra
> possibilities.
>
> IOW provide a nice upgrade path for the transition and a lot of the
> problems switching go away.
>
> Then again, it's probably nowhere near as easy as I make it sound :)
>
> Have a nice day,
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Feb 22, 9:49 am, alvhe...@commandprompt.com (Alvaro Herrera) wrote: > Andrew Dunstan wrote: > > It's also fair to say that this is a subject about which we usually get > > much more noise from partisans of other SCM systems than from the > > relatively small number of people who actually have to maintain the > > postgresql code. (As Tom has pointed out, our biggest pain point is the > > occasional wish to move things across directories.) While annoying, this is something that really only a problem for the CVS maintainer (and anyone who's stuck waiting for the maintainer to shuffle stuff). I suggest that while it would be nice to solve this problem, it's more of a bonus side-effect rather than a significant benefit to changing SCMs. > For example, currently if I have a patch and somebody reviews it and > opines that I have to change foo to bar; then I resubmit the patch. How > do they find out whether I actually changed foo to bar? Currently there > are two alternatives: > > 1. trust that I did it > 2. review the whole patch again > > With a distributed SCM, I could just patch the code and commit a new > revision in my branch to just change foo to bar, and then the reviewer > can check that I truly did what he wanted. > > Another easy thing to do is to track the current HEAD in a branch of > mine. Keeping patches up to date in parallel with other developments is > easier. Alvaro's arguments above suggest a significant, ongoing pay-off for everyone who writes patches, everyone who reviews patches and everyone who has to maintain separate patches. I won't attempt to quantify this pay-off, but it looks pretty significant to me. Andrew
Gregory Stark wrote: > You're still merging patches and reviewing patches by hand, without any of the > tools to, for example, view incremental changes in the branch, view the logs > of the branch, merge the branch into the code automatically taking into > account the known common ancestor. Instead of receiving a 20k patch without > any tools to work with it you would be given a branch name and be able to view > and merge it into the main branch using the tools. I don't see this as a win. I understand the ability to see the patch as separate revisions by the user, but for patch application, we really need to see the diff -c of the entire patch. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Gregory Stark wrote: > > You're still merging patches and reviewing patches by hand, without any of the > > tools to, for example, view incremental changes in the branch, view the logs > > of the branch, merge the branch into the code automatically taking into > > account the known common ancestor. Instead of receiving a 20k patch without > > any tools to work with it you would be given a branch name and be able to view > > and merge it into the main branch using the tools. > > I don't see this as a win. I understand the ability to see the patch as > separate revisions by the user, but for patch application, we really > need to see the diff -c of the entire patch. The fact that you're still thinking in "patch application" means you're still stuck in the CVS worldview. To "apply a patch" in a distributed SCM(*) really means to merge a branch into the main development branch. Of course, you can still see the entire "diff -c" if you want. (*) I'm not sure if this is true of all distributed SCMs, or just a property of Monotone. Really it's the only one I follow more-or-less closely. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Gregory Stark wrote: > > > You're still merging patches and reviewing patches by hand, without any of the > > > tools to, for example, view incremental changes in the branch, view the logs > > > of the branch, merge the branch into the code automatically taking into > > > account the known common ancestor. Instead of receiving a 20k patch without > > > any tools to work with it you would be given a branch name and be able to view > > > and merge it into the main branch using the tools. > > > > I don't see this as a win. I understand the ability to see the patch as > > separate revisions by the user, but for patch application, we really > > need to see the diff -c of the entire patch. > > The fact that you're still thinking in "patch application" means you're > still stuck in the CVS worldview. To "apply a patch" in a distributed > SCM(*) really means to merge a branch into the main development branch. > Of course, you can still see the entire "diff -c" if you want. How do I modify the patch before application if it comes from a branch? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > Gregory Stark wrote: > > > > You're still merging patches and reviewing patches by hand, without any of the > > > > tools to, for example, view incremental changes in the branch, view the logs > > > > of the branch, merge the branch into the code automatically taking into > > > > account the known common ancestor. Instead of receiving a 20k patch without > > > > any tools to work with it you would be given a branch name and be able to view > > > > and merge it into the main branch using the tools. > > > > > > I don't see this as a win. I understand the ability to see the patch as > > > separate revisions by the user, but for patch application, we really > > > need to see the diff -c of the entire patch. > > > > The fact that you're still thinking in "patch application" means you're > > still stuck in the CVS worldview. To "apply a patch" in a distributed > > SCM(*) really means to merge a branch into the main development branch. > > Of course, you can still see the entire "diff -c" if you want. > > How do I modify the patch before application if it comes from a branch? You commit your change to the branch. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Alvaro Herrera wrote: > > > Bruce Momjian wrote: > > > > Gregory Stark wrote: > > > > > You're still merging patches and reviewing patches by hand, without any of the > > > > > tools to, for example, view incremental changes in the branch, view the logs > > > > > of the branch, merge the branch into the code automatically taking into > > > > > account the known common ancestor. Instead of receiving a 20k patch without > > > > > any tools to work with it you would be given a branch name and be able to view > > > > > and merge it into the main branch using the tools. > > > > > > > > I don't see this as a win. I understand the ability to see the patch as > > > > separate revisions by the user, but for patch application, we really > > > > need to see the diff -c of the entire patch. > > > > > > The fact that you're still thinking in "patch application" means you're > > > still stuck in the CVS worldview. To "apply a patch" in a distributed > > > SCM(*) really means to merge a branch into the main development branch. > > > Of course, you can still see the entire "diff -c" if you want. > > > > How do I modify the patch before application if it comes from a branch? > > You commit your change to the branch. My typical cycle is to take the patch, apply it to my tree, then cvs diff and look at the diff, adjust the source, and rerun until I like the diff and apply. How do I do that with this setup? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > > My typical cycle is to take the patch, apply it to my tree, then cvs > diff and look at the diff, adjust the source, and rerun until I like the > diff and apply. How do I do that with this setup? The most similar to what you're doing would be to merge the patch's branch into yours. It's about exactly the same amount of work as applying a patch (a one liner if there are no conflicts). From that point you could continue exactly as you are now - with the additional benefit(?) that the checkin history of the branch should (I hope) be preserved through the merge process so the SCM's history would let you see which changes from the patch came from the submitter and which changes came from the modifications in your tree. (I think this SCM requirements list http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.htmlisone of the more interesting.Thetwo features I like about the distributed systems are # 5. Branching preserves full history # 6. Mergingpreserves full history.so the history of the branch (including which changescame from the submitter and which weremodificationsin your tree) are preserved when they're eventuallycommitted to head.)
Bruce Momjian wrote: > My typical cycle is to take the patch, apply it to my tree, then cvs > diff and look at the diff, adjust the source, and rerun until I like the > diff and apply. How do I do that with this setup? The same, except that you don't need to take the patch out of an email and into the repository -- the new code is already in the repository, sitting in someone's own branch. You can commit into that branch all the adjustments you want; and when you consider it ready, the only thing you have to do is "propagate" the change to the main development branch. Yes, it's nice. Consider this: Andrew develops some changes to PL/perl in his branch. Neil doesn't like something in those changes, so he commits a fix there. In the meantime, Tom has been busy with his own stuff and committing to the main branch; Andrew can track those changes by propagating from the main branch to his branch -- he doesn't need to fall behind and update his modified tree once a month and deal with umpteen conflicts. Of course, you can _also_ do the patch by email and correct stuff if you want. It's just not the best way to do it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > My typical cycle is to take the patch, apply it to my tree, then cvs > > diff and look at the diff, adjust the source, and rerun until I like the > > diff and apply. How do I do that with this setup? > > The same, except that you don't need to take the patch out of an email > and into the repository -- the new code is already in the repository, > sitting in someone's own branch. You can commit into that branch all > the adjustments you want; and when you consider it ready, the only thing > you have to do is "propagate" the change to the main development branch. > > Yes, it's nice. Consider this: Andrew develops some changes to PL/perl > in his branch. Neil doesn't like something in those changes, so he > commits a fix there. In the meantime, Tom has been busy with his own > stuff and committing to the main branch; Andrew can track those changes > by propagating from the main branch to his branch -- he doesn't need to > fall behind and update his modified tree once a month and deal with > umpteen conflicts. > > Of course, you can _also_ do the patch by email and correct stuff if you > want. It's just not the best way to do it. How to people get a branch? Do they have their own logins? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Yes, it's nice. Consider this: Andrew develops some changes to PL/perl
> in his branch. Neil doesn't like something in those changes, so he
> commits a fix there. In the meantime, Tom has been busy with his own
> stuff and committing to the main branch; Andrew can track those changes
> by propagating from the main branch to his branch -- he doesn't need to
> fall behind and update his modified tree once a month and deal with
> umpteen conflicts.
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in use
and everything to do with whether your "diff" command is AI-complete.
I note also that CVS does have the ability to merge changes across
branches, we just choose not to use it that way.
regards, tom lane
On Friday 23 February 2007 15:50, you wrote: > How to people get a branch? Do they have their own logins? If monotone is something like Git, you just create it in your local working copy and push is somewhere public when you are ready, or you can just generate the changeset and submit that. wt -- Warren Turkal (w00t)
* Bruce Momjian: >> The fact that you're still thinking in "patch application" means you're >> still stuck in the CVS worldview. To "apply a patch" in a distributed >> SCM(*) really means to merge a branch into the main development branch. >> Of course, you can still see the entire "diff -c" if you want. > > How do I modify the patch before application if it comes from a branch? You refuse to merge until you reach a point which is acceptable. One large project even gets so far as to ask the submitter to clean up history before merging it, so that all that polishing is gone and does not show up after the merge. In the official tree, there's just a clean sequence of incremental patches. I'm not really sure if this is the right model for every project. Personally, I'm a fan of the write-after-approval approach: per ACL, everybody has got full write access, but most developers might only apply their patches after some review and a formal go-ahead. This has the advantage that everyone can fix obvious mistakes or back out wrong patches if necessary, and it nicely distributes the integration overhead. But obviously, there are fairly successful projects which use very different models, and switching just because the technology is there to do things differently doesn't make much sense. But once you run into problems like tagging a release taking hours, you should really contemplate a move to Subversion. 8-P
On Friday 23 February 2007 00:55, Lukas Kahwe Smith wrote: > Anyone who followed the thread willing to list the mentioned > requirements as well as the pro's and con's of the differnent options in > the developer wiki [1]? Does the dev wiki even have a link from the site? I can't find a link under [1]. [1]http://www.postgresql.org/developer/ wt -- Warren Turkal (w00t)
Alvaro Herrera wrote: > Yes, it's nice. Consider this: Andrew develops some changes to PL/perl > in his branch. Neil doesn't like something in those changes, so he > commits a fix there. If I understand right, another advantage is that the SCM will keep track of which of those changes came from Neil and which from Andrew and that this history will be preserved when eventually merged with head. In contrast, with CVS I think detailed history of changes within Andrew's branch would be lost and only recorded as one large checkin in CVS. Right?
On Fri, Feb 23, 2007 at 04:24:29PM -0700, Warren Turkal wrote: > On Friday 23 February 2007 15:50, you wrote: > > How to people get a branch? Do they have their own logins? > > If monotone is something like Git, you just create it in your local working > copy and push is somewhere public when you are ready, or you can just > generate the changeset and submit that. One additional benefit... we've talked about allowing certain patches to be automatically verified by the buildfarm to guard against bitrot and provide additional testing, but one of the big issues has been how to distribute those patches. Using a distributed SCM would make it easier to do this; we'd just have to supply buildfarm machines with a list of approved branches that they should be pulling from (or perhaps some SCMs would allow a means of tagging that). -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Yes, it's nice. Consider this: Andrew develops some changes to PL/perl >> in his branch. Neil doesn't like something in those changes, so he >> commits a fix there. In the meantime, Tom has been busy with his own >> stuff and committing to the main branch; Andrew can track those changes >> by propagating from the main branch to his branch -- he doesn't need to >> fall behind and update his modified tree once a month and deal with >> umpteen conflicts. > > Yah know, the one bit of these pitches that always sounds like pure > snake oil is the claim that they offer some kind of mechanical solution > to merge conflicts. AFAICS that has nothing to do with the SCMS in use > and everything to do with whether your "diff" command is AI-complete. Well there is some difference in that it's easier to do that when you have the common ancestor. But it has more to do with being able to see the changes other people are making. In the above scenario imagine Neil had just emailed the fix and Andrew hadn't seen it for a week. Or more importantly that Neil had emailed the fix and someone else had also emailed a different fix somewhere else. Because they couldn't see each others changes they have no idea when they're generating the patch that they're generating it against old versions. > I note also that CVS does have the ability to merge changes across > branches, we just choose not to use it that way. And the reason why, I assume, is because it's hard to grant access to CVS without granting access to do anything at all to the whole repository. And CVS is fragile enough that that's pretty scary. There are lots of ways someone could mess up a CVS repository. The distributed systems sound neat and do sound like they match our style of working. But they seem like a big leap for a project that's still using a buggy unmaintained pile of spaghetti code for fear of change. Subversion is the path of least resistance in that nothing has to change, we can choose to use new features if we want but otherwise it's basically a CVS 2.0 with a new name (and active maintenance). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: > >> I note also that CVS does have the ability to merge changes across >> branches, we just choose not to use it that way. >> > > And the reason why, I assume, is because it's hard to grant access to CVS > without granting access to do anything at all to the whole repository. And CVS > is fragile enough that that's pretty scary. There are lots of ways someone > could mess up a CVS repository. > Every project I have been on that has used cross branch merge with CVS has tied itself in knots. Branch and never merge is by far the sanest way to operate. This is true regardless of any privs issue. The elephant in the room is that merging is *the* hard problem in SCM systems. Last time I wrestled with merge it was using ClearCase and drove me nuts. > The distributed systems sound neat and do sound like they match our style of > working. But they seem like a big leap for a project that's still using a > buggy unmaintained pile of spaghetti code for fear of change. Subversion is > the path of least resistance in that nothing has to change, we can choose to > use new features if we want but otherwise it's basically a CVS 2.0 with a new > name (and active maintenance). > > There is some truth in that. Also, many of the new systems have a little way to go on maturity - I'd like to see the dust settle some in this area. cheers andrew
On Friday 23 February 2007 08:30, Alvaro Herrera wrote: > Sorry, I mean Windows. We're taken pains to ensure Postgres runs on > Windows, we're not going to abandon that platform now. This is why I would propose the use of the CVS gateway on top of git. Also, Wikipedia claims there is a MingW32 port of git underway. > And there's a lot of platforms on which we'd have to make sure Monotone > also runs on. Our buildfarm currently has > http://buildfarm.postgresql.org/cgi-bin/show_status.pl Again, the CVS gateway should allow them to continue to function with minimal changes. Over time, they could be moved to Git. wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Friday 23 February 2007 08:30, Alvaro Herrera wrote: > > Sorry, I mean Windows. We're taken pains to ensure Postgres runs on > > Windows, we're not going to abandon that platform now. > > This is why I would propose the use of the CVS gateway on top of git. Also, > Wikipedia claims there is a MingW32 port of git underway. To be frank, I don't like Git's data model. Git has always seemed much too complex to use to me. I have more than enough with a single distributed SCM. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Friday 23 February 2007 17:30, Gregory Stark wrote: > The distributed systems sound neat and do sound like they match our style > of working. But they seem like a big leap for a project that's still using > a buggy unmaintained pile of spaghetti code for fear of change. Subversion > is the path of least resistance in that nothing has to change, we can > choose to use new features if we want but otherwise it's basically a CVS > 2.0 with a new name (and active maintenance). The interesting thing about Git is that is has two way sync support for a SVN repository also. You could run a Git repository pushing changes in real time to a SVN repository and present a CVS frontend also. I would like to try converting the CVS repository of PostgreSQL to Git and try setting some of this stuff up. Does anyone know how I could get the CVS repository files? wt -- Warren Turkal (w00t)
On Friday 23 February 2007 12:03, Andrew Hammond wrote: > While annoying, this is something that really only a problem for the > CVS maintainer (and anyone who's stuck waiting for the maintainer to > shuffle stuff). I suggest that while it would be nice to solve this > problem, it's more of a bonus side-effect rather than a significant > benefit to changing SCMs. But it's not only a problem for the CVS maintainer. The problem is either (1) that the file history doesn't follow the move or (2) if you move the file on the CVS server, the file always seems to have been in its new location. For (1), you can't easily find the history for a file, and for (2), you can't check out old version and expect them to just work. wt -- Warren Turkal (w00t)
On Sat, 24 Feb 2007, Warren Turkal wrote: > The interesting thing about Git is that is has two way sync support for a SVN > repository also. You could run a Git repository pushing changes in real time > to a SVN repository and present a CVS frontend also. I would like to try > converting the CVS repository of PostgreSQL to Git and try setting some of > this stuff up. Does anyone know how I could get the CVS repository files? Use cvsup, or if you don't want to go through the effort of getting that set up, use rsync: rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/ > > wt > -- Man is the only animal that can remain on friendly terms with the victims he intends to eat until he eats them. -- Samuel Butler (1835-1902)
On Friday 23 February 2007 23:10, Alvaro Herrera wrote: > To be frank, I don't like Git's data model. Git has always seemed > much too complex to use to me. I have more than enough with a single > distributed SCM. Have you ever tried cogito or any of the other apps for interacting with a git repo. Cogito makes it as simple as anything else I have seen out there. wt -- Warren Turkal (w00t)
On Saturday 24 February 2007 00:32, Jeremy Drake wrote: > Use cvsup, or if you don't want to go through the effort of getting that > set up, use rsync: > > rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/ Thanks for this. Is this documented somewhere that I should have looked? wt -- Warren Turkal (w00t)
On Wednesday 21 February 2007 21:23, Warren Turkal wrote: > Are there any plans to move to another SCMS in the future? I am curious, I > guess. Is it possible to obtain a mirror of the CVS repository? The version of CVS on the repository server is incompatible with cvsps (at least the version on Debian, which I believe is the latest). I'd like to try converting the CVS repository to Git and try the cvs gateway to see how well it works. The cvsps tool is used in the conversion process. Thanks, wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Friday 23 February 2007 17:30, Gregory Stark wrote: >> The distributed systems sound neat and do sound like they match our style >> of working. But they seem like a big leap for a project that's still using >> a buggy unmaintained pile of spaghetti code for fear of change. Subversion >> is the path of least resistance in that nothing has to change, we can >> choose to use new features if we want but otherwise it's basically a CVS >> 2.0 with a new name (and active maintenance). > > The interesting thing about Git is that is has two way sync support for a SVN > repository also. You could run a Git repository pushing changes in real time > to a SVN repository and present a CVS frontend also. I would like to try > converting the CVS repository of PostgreSQL to Git and try setting some of > this stuff up. Does anyone know how I could get the CVS repository files? AFAIK, git still does not support windows properly[1], which I would say is a killer... Unless you can of course to everything you need through one of those frontend protocols, but if you can do everything that way then why would you need git in the first place? //Magnus [1] per git homepage, only cygwin is supported. Cygwin != windows, and not acceptable for a windows developer. The only other option being a pure java plugin to Eclipse, which would require Eclipse, which is of course also not acceptable. Per: http://git.or.cz/gitwiki/WindowsInstall.
On Sat, 24 Feb 2007, Warren Turkal wrote: > On Saturday 24 February 2007 00:32, Jeremy Drake wrote: > > Use cvsup, or if you don't want to go through the effort of getting that > > set up, use rsync: > > > > rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/ > > Thanks for this. Is this documented somewhere that I should have looked? CVSup is: http://developer.postgresql.org/pgdocs/postgres/cvsup.html rsync is a fairly new (and AFAIK, undocumented) method. I had to go back in the mailing list archives to find the reference: http://archives.postgresql.org/pgsql-hackers/2006-03/msg01081.php -- Chicken Little was right.
Jeremy Drake wrote: > > rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/ > > > The buildfarm howto has somewhat more complete instructions (including how to adjust the various cvs config files if you need to). I set it up the other day - took me about 10 minutes. http://pgfoundry.org/docman/view.php/1000040/4/PGBuildFarm-HOWTO.txt - see point 12. cheers andrew
On Saturday 24 February 2007 00:55, Magnus Hagander wrote: > AFAIK, git still does not support windows properly[1], which I would say > is a killer... Unless you can of course to everything you need through > one of those frontend protocols, but if you can do everything that way > then why would you need git in the first place? You might be able to get the cvs functionality. That's not necessarily everything you could have, but it means that you can operate without losing functionality for some developers while increasing functionality for a number of developers. I think would be a pretty good thing. wt -- Warren Turkal (w00t)
On Saturday 24 February 2007 00:24, Warren Turkal wrote: > The interesting thing about Git is that is has two way sync support for a > SVN repository also. You could run a Git repository pushing changes in real > time to a SVN repository and present a CVS frontend also. I would like to > try converting the CVS repository of PostgreSQL to Git and try setting some > of this stuff up. Does anyone know how I could get the CVS repository > files? As a followup, the cvs2svn conversion says the following. Error summary: ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v' ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v' ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v' Exited due to fatal error(s). I do believe that the files are actually malformed. If anyone knows how to modify them such that they are valid, please let me know. I have just deleted them since they are in an Attic directory. I am in the middle of importing 25825 revisions into a svn repository based on a snapshot of the repository files that I pulled last night. I will probably post some further results once the import is is done. wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Saturday 24 February 2007 00:24, Warren Turkal wrote: >> The interesting thing about Git is that is has two way sync support for a >> SVN repository also. You could run a Git repository pushing changes in real >> time to a SVN repository and present a CVS frontend also. I would like to >> try converting the CVS repository of PostgreSQL to Git and try setting some >> of this stuff up. Does anyone know how I could get the CVS repository >> files? > > As a followup, the cvs2svn conversion says the following. > > Error summary: > ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v' > ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v' > ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v' > Exited due to fatal error(s). > > I do believe that the files are actually malformed. If anyone knows > how to modify them such that they are valid, please let me know. I > have just deleted them since they are in an Attic directory. When I do the conversion every four hours, I remove the perl5 directory. This is what the converted tree looks like: http://projects.commandprompt.com/public/pgsql Joshua D. Drake > > I am in the middle of importing 25825 revisions into a svn repository > based on a snapshot of the repository files that I pulled last night. > I will probably post some further results once the import is is done. > > wt -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
Warren Turkal wrote: > On Saturday 24 February 2007 00:55, Magnus Hagander wrote: > >> AFAIK, git still does not support windows properly[1], which I would say >> is a killer... Unless you can of course to everything you need through >> one of those frontend protocols, but if you can do everything that way >> then why would you need git in the first place? >> > > You might be able to get the cvs functionality. That's not necessarily > everything you could have, but it means that you can operate without losing > functionality for some developers while increasing functionality for a number > of developers. I think would be a pretty good thing. > > I would not be at all happy with making such a compromise. Proper support for all the platforms we build on is an absolute prequisite, as far as I am concerned. I'm not prepared to treat Windows as a second-class citizen. I also think that if we change to another SCM it should be something in widespread use in FOSS systems - ideally also something supported already in many distributions. As I said earlier, there is no hurry. cheers andrew
Joshua D. Drake wrote: > Warren Turkal wrote: > > As a followup, the cvs2svn conversion says the following. > > > > Error summary: > > ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v' > > ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v' > > ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v' > > Exited due to fatal error(s). > > > > I do believe that the files are actually malformed. If anyone knows > > how to modify them such that they are valid, please let me know. I > > have just deleted them since they are in an Attic directory. > > When I do the conversion every four hours, I remove the perl5 directory. > This is what the converted tree looks like: > > http://projects.commandprompt.com/public/pgsql Keep in mind that the repository as converted by Josh, above, is strangely corrupted in weird and unpredictable ways. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Saturday 24 February 2007 15:18, Alvaro Herrera wrote: > Keep in mind that the repository as converted by Josh, above, is > strangely corrupted in weird and unpredictable ways. Would you care to elaborate on that statement? I'd like to check my converted repositories for what you're referring to. Thanks, wt -- Warren Turkal (w00t)
Alvaro Herrera wrote: > Joshua D. Drake wrote: >> Warren Turkal wrote: > >>> As a followup, the cvs2svn conversion says the following. >>> >>> Error summary: >>> ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v' >>> ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v' >>> ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v' >>> Exited due to fatal error(s). >>> >>> I do believe that the files are actually malformed. If anyone knows >>> how to modify them such that they are valid, please let me know. I >>> have just deleted them since they are in an Attic directory. >> When I do the conversion every four hours, I remove the perl5 directory. >> This is what the converted tree looks like: >> >> http://projects.commandprompt.com/public/pgsql > > Keep in mind that the repository as converted by Josh, above, is > strangely corrupted in weird and unpredictable ways. Yes, that is actually the point. I mentioned further up in the thread that our conversion is not perfect and we use cvs2svn to do that conversion. The problem Warren mentions is one that cvs2svn can't deal with, which is that the interfaces/perl5 stuff exists in one place but no in another. I have no idea if it is how the directories were removed from cvs or what, I only know that removing the directories in the repo entirely allows the conversion to continue. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
Warren Turkal wrote: > On Saturday 24 February 2007 15:18, Alvaro Herrera wrote: > > Keep in mind that the repository as converted by Josh, above, is > > strangely corrupted in weird and unpredictable ways. > > Would you care to elaborate on that statement? I'd like to check my > converted repositories for what you're referring to. I don't know :-( I've tried to use the Trac site looking for particular changesets and found that for some of them, the list of files are out of sync with reality, and sometimes the diff don't have anything to do with what the commit message says. I've never been sure if the problem is the repo itself, or the Trac interface. After discovering the problem independently a couple of times (the second time I had forgotten that I had already found a problem), I stopped using it and reverted to using cvs2cl and cvsup. I imagine the problems are caused by manual mangling of the files in the early days, like the perl5 dir stuff you found. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On 2/24/07, Joshua D. Drake <jd@commandprompt.com> wrote:
head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
head 1.3;
access;
symbols
Release-1-6-0:1.1.1.1
creation:1.1.1.1
creation:1.1.1; <<< What the heck happened here?
locks; strict;
comment @# @;
The error is actually that the label creation is pointing to TWO different revisions. CVS seems to deal with this issue by ignoring the second relationship of the "creation" label to revision.
There is also a few files that are both in Attic and the regular directory, which is also not supposed to happen. Also, is it me or does CVS ignore Attic files when you export a specific label?
>>> ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v'
>>> ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v'
>>> ERROR: Multiple definitions of the symbol 'creation' in '../pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v'
head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v
head 1.3;
access;
symbols
Release-1-6-0:1.1.1.1
creation:1.1.1.1
creation:1.1.1; <<< What the heck happened here?
locks; strict;
comment @# @;
The problem Warren mentions is one that cvs2svn can't deal with, which
is that the interfaces/perl5 stuff exists in one place but no in
another. I have no idea if it is how the directories were removed from
cvs or what, I only know that removing the directories in the repo
entirely allows the conversion to continue.
The error is actually that the label creation is pointing to TWO different revisions. CVS seems to deal with this issue by ignoring the second relationship of the "creation" label to revision.
There is also a few files that are both in Attic and the regular directory, which is also not supposed to happen. Also, is it me or does CVS ignore Attic files when you export a specific label?
On 2/24/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
cvs2svn will group multiple independent commit's together, I think if it sees commits within 300 seconds (should be adjustable) of each other it will group the comments all together. This may be the issue you are seeing.
I don't know :-( I've tried to use the Trac site looking for particular
changesets and found that for some of them, the list of files are out of
sync with reality, and sometimes the diff don't have anything to do with
what the commit message says.
cvs2svn will group multiple independent commit's together, I think if it sees commits within 300 seconds (should be adjustable) of each other it will group the comments all together. This may be the issue you are seeing.
On Saturday 24 February 2007 16:47, Chad Wagner wrote: > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v > head 1.3; > access; > symbols > Release-1-6-0:1.1.1.1 > creation:1.1.1.1 > creation:1.1.1; <<< What the heck happened here? > locks; strict; > comment @# @; Can a cvs maintainer please correct this file by adding a ";" after the first "creation" line and removing the second "creation" line? wt -- Warren Turkal (w00t)
On Friday 23 February 2007 11:11, Joshua D. Drake wrote: > If you are looking for a CVS replacement, that replacement is SVN. I > don't think anyone can reasonably argue against that statement. It seems to me that the best reason for keeping CVS is that the build farm uses it. There are solutions for maintaining anonymous CVS access (e.g. [1]) when moving to SVN. A secondary problem is that of portability. SVN is the best supported for portability. I was able to find links to downloads for most of the archs of the build farm from the Subversion site. The previously mentioned ability to maintain CVS anonymous access should help with this part also. SVN also has a lot of tools for different platforms. There is even plugin for Visual Studio for Windows if that kind of thing trips your trigger. Moving to SVN would maintain the same model of development and get many nice features (e.g. atomic commit, cheap tagging, etc.). This type of transition has been executed successfully by many open source projects, including KDE (big development group) and Bacula (small development group). What would you all think about moving to SVN if the anon CVS checkout can be made to work? I'll even volunteer to set it up. [1]http://sam.zoy.org/writings/programming/svn2cvs.html wt -- Warren Turkal (w00t)
Warren Turkal <wt@penguintechs.org> writes:
> What would you all think about moving to SVN if the anon CVS checkout can be
> made to work? I'll even volunteer to set it up.
What's with the high pressure sales tactics? It's already been
explained to you that the key PG developers feel no particular reason
to change at this time.
Given the amount of activity currently going on in the SCMS world,
it seems to me that we should wait another year or two before making
a decision on switching. If CVS were a major pain point for us
then I'd be willing to consider moving now, but it still gets the job
done.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Warren Turkal <wt@penguintechs.org> writes: >> What would you all think about moving to SVN if the anon CVS checkout can be >> made to work? I'll even volunteer to set it up. > > What's with the high pressure sales tactics? It's already been > explained to you that the key PG developers feel no particular reason > to change at this time. Not to mention that the beginning of feature freeze sounds like a particularly bad time to do this. :) -Doug
On Saturday 24 February 2007 19:18, Tom Lane wrote: > What's with the high pressure sales tactics? It's already been > explained to you that the key PG developers feel no particular reason > to change at this time. I am not trying to be high pressure. I just wanted to give something back to the PostgreSQL community, both by contributing to the discussion and offering to contribute time to the effort if I could help that way. I am also not trying to get you to do this tomorrow. I'd like to help it happen, if possible, though. > Given the amount of activity currently going on in the SCMS world, > it seems to me that we should wait another year or two before making > a decision on switching. If CVS were a major pain point for us > then I'd be willing to consider moving now, but it still gets the job > done. I am sure that CVS will allow the maintenance of code into the future. There are just some systems out there that help manage it better. SVN appears to be the best CVS resplacement right now. SVN does everything that CVS does and then some. SVN has also been around for over 5 years now and is pretty mature and portable. I think that most of the benefits become more clear after moving to the system. As for timing, I am sure that the beginning of a development cycle would be better than the beginning of a freeze preparing for release, but it seems that not checking things out in the near term will only delay the ability to reap the benefits of the newer SCMS systems. wt -- Warren Turkal (w00t)
On Saturday 24 February 2007 19:51, Douglas McNaught wrote: > Not to mention that the beginning of feature freeze sounds like a > particularly bad time to do this. :) I never encouraged doing it right now, but I'd like to help when and if it does happen. I think at the begginning of a new dev cycle would probably be a more appropriate time. However, that doesn't mean we can't start thinking now. wt -- Warren Turkal (w00t)
Douglas McNaught wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > >> Warren Turkal <wt@penguintechs.org> writes: >> >>> What would you all think about moving to SVN if the anon CVS checkout can be >>> made to work? I'll even volunteer to set it up. >>> >> What's with the high pressure sales tactics? It's already been >> explained to you that the key PG developers feel no particular reason >> to change at this time. >> > > Not to mention that the beginning of feature freeze sounds like a > particularly bad time to do this. :) > > > And it misses the point I have made, that I don't really want compatibility garteways etc for the buildfarm, as it is meant to mimic the process that woluld followed by a human to check out, build and test by hand. If pg moves then the buildfarm will need to move with it. This decision really belongs to the handful of people who do most of the maintenance and live with most of any CVS pain that exists: such as Tom, Bruce, Peter, Neil, Alvaro. Othe people have a right to voice an opinion, but nobody should be pushing on it. If we were to move now then subversion would probably be the best choice, on maturity grounds if nothing else. That might well not be true in a year or two. I don't want to move more than once, so waiting and seeing makes a lot of sense to me. cheers andrew
Warren Turkal wrote: > On Saturday 24 February 2007 19:51, Douglas McNaught wrote: > >> Not to mention that the beginning of feature freeze sounds like a >> particularly bad time to do this. :) >> > > I never encouraged doing it right now, but I'd like to help when and if it > does happen. I think at the begginning of a new dev cycle would probably be a > more appropriate time. However, that doesn't mean we can't start thinking > now. > > > Warren, what part of "We'd like to watch the SCM space for a while before making any decisions" don't you understand? cheers andrew
On Saturday 24 February 2007 20:27, Andrew Dunstan wrote: > If we were to move now then subversion would probably be the best > choice, on maturity grounds if nothing else. That might well not be true > in a year or two. I don't want to move more than once, so waiting and > seeing makes a lot of sense to me. This all sounds truly reasonable. I am glad that I could get all your opinions on the subject. If you do decide to move to anything else in a couple years, hopefully I can help the process somehow. Thanks, wt -- Warren Turkal (w00t)
> Warren,
>
> what part of "We'd like to watch the SCM space for a while before making
> any decisions" don't you understand?
Andrew hold on,
He didn't say *which* dev cycle. He is just enthusiastic and the reality
is this project is about 2 years overdue to run screaming from the
burning building that is CVS.
Does that mean we should change? Only if the people doing development
feel a need to change. However, there is a distinct feeling of *OMG
CHANGE RUN RUN* whenever it comes to anything infrastructure (and
frankly some parts of code) in this project.
It is certainly valid that, if it ain't broke don't fix it. CVS is not
broke for us, it is however barely maintained. That in itself is enough
to consider moving off.
The fact that SVN *is* a CVS replacement and does not change most of the
workflow of existing developers is an additional strong argument to use it.
All that being said, I welcome Warren's enthusiasm, a lot of the hackers
in this group could use a strong dose of positive thinking about change
around here.
Lastly, who really cares? Does it really matter? No. I would much rather
Warren (if he has the skills) put some effort into Patch Review.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Lastly, who really cares? Does it really matter? No. I would much rather
> Warren (if he has the skills) put some effort into Patch Review.
That's pretty much the bottom line. CVS is not so broken that it's a
problem for us today. I have no doubt that it could be a problem if we
had different usage patterns, but we don't. We have the opportunity to
wait and see what will emerge in the SCMS competition, and IMHO that's
what we should do. There are many more-pressing things for us to spend
time on right now than an SCMS conversion.
I also tend to think that a conversion will be easier in a year or two
than it is today --- the problems noted upthread are certainly a
heads-up that cvs2svn is not yet as robust as one could wish.
regards, tom lane
Tom Lane wrote: > I also tend to think that a conversion will be easier in a year or two > than it is today --- the problems noted upthread are certainly a > heads-up that cvs2svn is not yet as robust as one could wish. Yes, which is why Markus is working on improved algorithms for Monotone. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Joshua D. Drake wrote: > He didn't say *which* dev cycle. He is just enthusiastic and the reality > is this project is about 2 years overdue to run screaming from the > burning building that is CVS. > > Does that mean we should change? Only if the people doing development > feel a need to change. However, there is a distinct feeling of *OMG > CHANGE RUN RUN* whenever it comes to anything infrastructure (and > frankly some parts of code) in this project. > > It is certainly valid that, if it ain't broke don't fix it. CVS is not > broke for us, it is however barely maintained. That in itself is enough > to consider moving off. > > The fact that SVN *is* a CVS replacement and does not change most of the > workflow of existing developers is an additional strong argument to use it. > > Joshua, In my case at least you are 180 degrees wrong. The reason I want to wait is that I don't want the replacement to be svn. Why go throught the pain of adjustment just to be in more or less the same place? That's why I encouraged you to try setting up some mirrors to other systems, notably Mercurial which looks to very promising. (It's written in Python, and has a Trac plugin - it should appeal to you strongly). cheers andrew
On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote: > Richard Levitte - VMS Whacker wrote: > > In message <45DE9071.5020909@bluegap.ch> on Fri, 23 Feb 2007 07:57:53 +0100, Markus Schiltknecht <markus@bluegap.ch>said: > > > > markus> Uh, yah. But I was refering to the "lots of opinions on what > > markus> replacement system to use". This has not much to do with the > > markus> want or need (for lack of a better alternative) to stay with > > markus> CVS, IMO. > > > > Oh, it's an academic discussion? Sorry, didn't catch that. > > It's only academic because Monotone is not ready. As soon as it is > ready we will be pushing much harder. This invites the obvious question -- in which ways in monotone not ready? Not that I'm trying to imply that monotone *is* ready, of course. -- hendrik
In message <45DE9071.5020909@bluegap.ch> on Fri, 23 Feb 2007 07:57:53 +0100, Markus Schiltknecht <markus@bluegap.ch> said: markus> Uh, yah. But I was refering to the "lots of opinions on what markus> replacement system to use". This has not much to do with the markus> want or need (for lack of a better alternative) to stay with markus> CVS, IMO. Oh, it's an academic discussion? Sorry, didn't catch that. Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte richard@levitte.org http://richard.levitte.org/ "When I became a man I put away childish things, includingthe fear of childishness and the desire to be very grown up." -- C.S. Lewis
In message <20070223134213.GJ7744@alvh.no-ip.org> on Fri, 23 Feb 2007 10:42:13 -0300, Alvaro Herrera <alvherre@commandprompt.com>said: alvherre> Richard Levitte - VMS Whacker wrote: alvherre> > In message <45DE9071.5020909@bluegap.ch> on Fri, 23 Feb 2007 07:57:53 +0100, Markus Schiltknecht <markus@bluegap.ch>said: alvherre> > alvherre> > markus> Uh, yah. But I was refering to the "lots of alvherre> > markus> opinions on what replacement system to use". This alvherre> > markus> has not much to do with the want or need (for lack alvherre> > markus> of a better alternative) to stay with CVS, IMO. alvherre> > alvherre> > Oh, it's an academic discussion? Sorry, didn't catch that. alvherre> alvherre> It's only academic because Monotone is not ready. As soon alvherre> as it is ready we will be pushing much harder. You know, I wasn't trying to push any SCM in particular, even though I did mention monotone in one post. Cheers, Richard ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte richard@levitte.org http://richard.levitte.org/ "When I became a man I put away childish things, includingthe fear of childishness and the desire to be very grown up." -- C.S. Lewis
On Fri, Feb 23, 2007 at 11:28:07AM -0300, Alvaro Herrera wrote: > hendrik@topoi.pooq.com wrote: > > On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote: > > > Richard Levitte - VMS Whacker wrote: > > > > In message <45DE9071.5020909@bluegap.ch> on Fri, 23 Feb 2007 07:57:53 +0100, Markus Schiltknecht <markus@bluegap.ch>said: > > > > > > > > markus> Uh, yah. But I was refering to the "lots of opinions on what > > > > markus> replacement system to use". This has not much to do with the > > > > markus> want or need (for lack of a better alternative) to stay with > > > > markus> CVS, IMO. > > > > > > > > Oh, it's an academic discussion? Sorry, didn't catch that. > > > > > > It's only academic because Monotone is not ready. As soon as it is > > > ready we will be pushing much harder. > > > > This invites the obvious question -- in which ways in monotone not > > ready? Not that I'm trying to imply that monotone *is* ready, of > > course. > > Time to get the initial pull is too long, mostly. Also, having the > policy branch stuff will be good, if nothing else because it'll mean > having 1.0 out, in turn meaning UI stability, etc. And getting Markus' > work on the CVS import will be good too (I haven't tried converting > Postgres' entire CVS repo in a while, and that certainly is a must). > > I don't think we're going to get a one-shot migration, so Cristof's work > on CVS takeover would be really nice to have so that some of us can > create an "alternative" repo and cater for those that will continue to > use CVS for a while. Yes, interoperability with other revision management systems is a problem for all of the revision management systems. It might be de-facto-solved it one system manages to talk effectively to the important other ones -- it won't be solved permanantly until there are adequate standard, system-independent protocols ... I don't see that coming soon. And there;s the problem of welcoming the prodigal son. A file gets away from the revision management system, and. much later, returns, much changed from the experience. How should we slot it back into the system? -- hendrik
On Sat, Feb 24, 2007 at 10:27:38PM -0500 I heard the voice of Andrew Dunstan, and lo! it spake thus: > > This decision really belongs to the handful of people who do most of > the maintenance and live with most of any CVS pain that exists: such > as Tom, Bruce, Peter, Neil, Alvaro. Othe people have a right to > voice an opinion, but nobody should be pushing on it. One thing that the DVCS crowd pushes is that that's _not_ the whole story. With CVS (or other centralized systems), the VCS is a development tool for the few core people, and a glorified FTP/snapshotting system for everyone else. With a DVCS, _everybody_ gets a development tool out of it. ObBias: After much resistance, I drank the distributed Kool-Aid. My poison of choice is bzr, which is very probably not ready performance-wise for Pg. So, I also look forward to a switch happening not now, but in a year or two, when the performance failings are historical and bzr can be chosen 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
On Fri, 2007-02-23 at 18:02 -0500, Tom Lane wrote: > Yah know, the one bit of these pitches that always sounds like pure > snake oil is the claim that they offer some kind of mechanical solution > to merge conflicts. AFAICS that has nothing to do with the SCMS in use > and everything to do with whether your "diff" command is AI-complete. Did you do any research to support that assertion? The nature and quality of the merge algorithm used actually differs significantly between SCMs. The ability to do history-sensitive merges actually results in a significant reduction in the need for manual conflict resolution. For one example among many, see the discussion around a new proposed merge algorithm for Codeville: http://lists.zooko.com/pipermail/revctrl/2005-May/000005.html http://revctrl.org/PreciseCodevilleMerge Or the "Mark Merge" algorithm used by Monotone: http://monotone.ca/docs/Mark_002dMerge.html http://revctrl.org/MarkMerge Claiming that all this amounts to "snake oil" is plainly wrong, I think. > I note also that CVS does have the ability to merge changes across > branches, we just choose not to use it that way. As far as I know, CVS does not provide a way to do a 3-way merge without considerable manual effort (e.g. using a standalone tool to do the actual merge). -Neil
Matthew D. Fuller wrote: > On Sat, Feb 24, 2007 at 10:27:38PM -0500 I heard the voice of > Andrew Dunstan, and lo! it spake thus: > >> This decision really belongs to the handful of people who do most of >> the maintenance and live with most of any CVS pain that exists: such >> as Tom, Bruce, Peter, Neil, Alvaro. Othe people have a right to >> voice an opinion, but nobody should be pushing on it. >> > > One thing that the DVCS crowd pushes is that that's _not_ the whole > story. With CVS (or other centralized systems), the VCS is a > development tool for the few core people, and a glorified > FTP/snapshotting system for everyone else. With a DVCS, _everybody_ > gets a development tool out of it. > > > I don't really drink this koolaid, at least not to the extent of disavowing what I said above. There might well be good reasons for using a distributed SCM system, and if you look elsewhere in this thread you'll see me eyeing Mercurial, which is one such, quite favorably, and stating quite definitely that I hope we don't move to Subversion, which would be the main centralised alternative. But no matter what system is used, there will be a smallish number who will maintain the branches that bear our name, and I still think they are the people with the principal responsibility in the matter. I'm more interested in making things as easy as possible for Tom and Bruce than I am for anyone else. cheers andrew
On Thu, 2007-02-22 at 14:49 -0300, Alvaro Herrera wrote: > For example, currently if I have a patch and somebody reviews it and > opines that I have to change foo to bar; then I resubmit the patch. How > do they find out whether I actually changed foo to bar? Currently there > are two alternatives: > > 1. trust that I did it > 2. review the whole patch again Or use interdiff, and then review the incremental changes. BTW, I think an important benefit of switching to a distributed SCM is that it could make life significantly simpler for people maintaining long-lived branches of the Postgres source. That includes both individual developers working on complex features, but also companies that maintain a branch/fork of the Postgres source for one reason or another. At the moment, this requires considerable manual effort: people often end up manually importing periodic snapshots of the upstream Postgres source into their SCM system at various times, and then merging the changes with their private tree by hand. Personally, I'd definitely be in favour of evaluating the alternative SCMs, and switching *at some point*, although it may be that none of the alternatives are mature enough for us to switch yet. In the past, I've converted the Postgres CVS tree to both darcs and monotone. Darcs was completely unusable: even though I didn't import the initial CVS revision history, after a few months of merging in upstream fixes via Tailor, the merging process began to take days of CPU time (before I killed it off). So unless the Darcs algorithms change fundamentally from the 1.0.4-era approach, I don't think it would be scalable enough for us. Monotone worked pretty well -- I'd include it in the set of plausible SCM candidates, along with Mercurial. I agree with Andrew that there's not much to be gained by switching to SVN. -Neil
On Sun, Feb 25, 2007 at 06:28:20PM -0500 I heard the voice of Andrew Dunstan, and lo! it spake thus: > > I don't really drink this koolaid, at least not to the extent of > disavowing what I said above. Oh, don't take my message as "You're wrong, you're not taking into account [...]". It was meant more as a "This is a convenient place to make [...] explicit". It seems that there are really 3 sequential questions here. 1) Do we switch VCS's? The averaged answer to this is pretty much "Probably, but not right now, and not in the very near future". Given that,the rest of the discussion is probably somewhat pointless; at the least it should be carried out with this answerkept firmly in mind. 2) Do we go the DVCS route?, and only after THAT is resolved do we go on to: 3) Which VCS? The feature/capability lists of the various DVCS's contain a mix of those features which are inherent in (or at least pretty much universal among) DVCS's as a class, and those which are more particular to the given system. But in a discussion of which VCS to (hypothetically) use, you really want to separate them out so you can know when you're arguing for/against $SYSTEM, and when you're arguing for/against $CLASS_OF_SYSTEMS. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
On Sun, Feb 25, 2007 at 06:06:57PM -0500 I heard the voice of Neil Conway, and lo! it spake thus: > > The ability to do history-sensitive merges actually results in a > significant reduction in the need for manual conflict resolution. I would say that a far greater contributor in practice would simply be frequency. If you diverge on your significant feature for 6 months, then try to merge in upstream changes from the main dev, you will be in hell no matter what merge algorithm you use. If you merge in upstream changes every few days, however, you will have many fewer and much simplier conflicts to deal with. A VCS that makes frequent merges easy results in easier conflict handling, not by some magical auto-resolution, but just by letting you do it in ongoing regular and small bites. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
On Saturday 24 February 2007 23:11, Tom Lane wrote: > I also tend to think that a conversion will be easier in a year or two > than it is today --- the problems noted upthread are certainly a > heads-up that cvs2svn is not yet as robust as one could wish. Cvs2svn seems to make as much sense of CVS data as possible. The only real problem I have seen is with regard to the malformed files I mentioned earlier. I haven't seen any other concrete examples. Could someone fix the previously mentioned files in the CVS respository to be valid? After fixing those files, I get no messages during import except that some commit comments appear to be in some encoding other than ascii. I am in the middle of checking commits involving those files to make sure they make sense. wt -- Warren Turkal (w00t)
Warren Turkal <wt@penguintechs.org> writes:
> On Saturday 24 February 2007 23:11, Tom Lane wrote:
>> I also tend to think that a conversion will be easier in a year or two
>> than it is today --- the problems noted upthread are certainly a
>> heads-up that cvs2svn is not yet as robust as one could wish.
> Cvs2svn seems to make as much sense of CVS data as possible. The only real
> problem I have seen is with regard to the malformed files I mentioned
> earlier. I haven't seen any other concrete examples.
It was mentioned upthread that Josh has seen repeated problems with his
conversions. I too would like to see some details about that. One
thing that I personally would find to be a showstopper for any proposed
switch is if it fails to maintain our change histories; in particular,
if it's not still possible to pull an exact copy of any given prior
release, it'll be no sale. I gather from this thread that svn has by
far the closest storage model to cvs of any of the available
alternatives ... so if svn has conversion problems, what's it gonna
be like with another one?
regards, tom lane
On Sunday 25 February 2007 23:23, Tom Lane wrote: > It was mentioned upthread that Josh has seen repeated problems with his > conversions. I too would like to see some details about that. One > thing that I personally would find to be a showstopper for any proposed > switch is if it fails to maintain our change histories; in particular, > if it's not still possible to pull an exact copy of any given prior > release, it'll be no sale. I gather from this thread that svn has by > far the closest storage model to cvs of any of the available > alternatives ... so if svn has conversion problems, what's it gonna > be like with another one? With atomic commits, the exports from svn to other SCMSes seem to work better than from cvs to svn (or any other for that matter). I believe the reason is that you have to infer the commits in cvs whereas it is explicit in the other systems. To convert to git, for instance, I converted to svn and then imported that. wt -- Warren Turkal (w00t)
On Sunday 25 February 2007 23:23, Tom Lane wrote: > It was mentioned upthread that Josh has seen repeated problems with his > conversions. I am manually inspecting the diff between CVS tag REL_8_1_0 and SVN tag tags/REL_8_1_0/pgsql, and I am not finding any differences in code short of the $Id$-type keyword lines. However, I am having a problem with encodings in some of the files. How does cvs handle files with different encodings? For instance, it looks like the Chinese documentation gets messed up upon svn conversion. wt -- Warren Turkal (w00t)
Alvaro Herrera wrote: > Warren Turkal wrote: >> On Saturday 24 February 2007 15:18, Alvaro Herrera wrote: >>> Keep in mind that the repository as converted by Josh, above, is >>> strangely corrupted in weird and unpredictable ways. >> Would you care to elaborate on that statement? I'd like to check my >> converted repositories for what you're referring to. > > I don't know :-( I've tried to use the Trac site looking for particular > changesets and found that for some of them, the list of files are out of > sync with reality, and sometimes the diff don't have anything to do with > what the commit message says. > > I've never been sure if the problem is the repo itself, or the Trac > interface. After discovering the problem independently a couple of > times (the second time I had forgotten that I had already found a > problem), I stopped using it and reverted to using cvs2cl and cvsup. > > I imagine the problems are caused by manual mangling of the files in the > early days, like the perl5 dir stuff you found. Hmm, if you only checked using the Trac interface, maybe this is an issue with re-creating the SVN repo. Joshua, do you run "trac-admin /path/to/trac/env resync" after rebuilding the repository? (This command would re-sync the trac database with the repository.) Otherwise I would certainly expect such issues as Alvaro describes. Best Regards Michael Paesold
Hi, Andrew Dunstan wrote: >> O.k. everyone pay attention, I am about to agree with Greg! ;) >> >> Greg are their tools to migrate CVS to monotone or whatever your >> favorite is? The reason I ask is that I migrate the CVS to SVN every 4 >> hours I think it is and it isn't perfect. monotone ships it's own cvs_import. I'm about to improve that, using roughly the same algorithm as cvs2svn 2.0. The cvs2svn people are very well aware that their version 1.x is good, but has problems in some areas. > There is a generic conversion tool called Tailor that might help you: > http://www.darcs.net/DarcsWiki/Tailor Tailor does not have support for branches, but can only convert one branch at a time. And it is not half as clever as cvs2svn regarding clever reconstruction of broken or manually tweaked CVS repositories. Regards Markus
Hi, Matthew D. Fuller wrote: > I would say that a far greater contributor in practice would simply be > frequency. If you diverge on your significant feature for 6 months, > then try to merge in upstream changes from the main dev, you will be > in hell no matter what merge algorithm you use. Do you have experience with automatic merging tools, to back up this assertion. If so I'd be curious to know. I'm maintaining the Postgres-R branch since about late PostgreSQL 7.4 using monotone's cvs_import and propagating from the original PostgreSQL repository to my Postgres-R branch. And even if I propagate quite rarely, automatic merge tools (i.e. monotone) helped me a *great deal(tm)*. (What's still awkward, is the lacking cvs_import.) > If you merge in > upstream changes every few days, however, you will have many fewer and > much simplier conflicts to deal with. A VCS as good as monotone gives you the option to merge random revisions in between. Thus, if you didn't merge for six months, you can easily do incremental merges and i.e. do six times a merge of one month worth of mainline code. Of course, that still seems like more work, than if you do it frequently :-) But the VCS should give you the option and let *you* choose, instead of enforcing whatever it thinks should be good for you. > A VCS that makes frequent merges easy results in easier conflict > handling, not by some magical auto-resolution, but just by letting you > do it in ongoing regular and small bites. I disagree, by experience. And please note, that it's not magic, but (in case of monotone) a provably correct (and simple to understand, I might add) algorithm which merges cleanly whenever possible. Regards Markus
Hi, Tom Lane wrote: > Yah know, the one bit of these pitches that always sounds like pure > snake oil is the claim that they offer some kind of mechanical solution > to merge conflicts. AFAICS that has nothing to do with the SCMS in use > and everything to do with whether your "diff" command is AI-complete. You should have said "merge" command. Every tried that? Or kdiff3? Try it, you will be surprised! Regards Markus
Hi, Warren Turkal wrote: > Cvs2svn seems to make as much sense of CVS data as possible. The only real > problem I have seen is with regard to the malformed files I mentioned > earlier. cvs2svn (1.x) still heavily relies on timestamps, which is certainly correct in most cases. But they are switching to a graph based approach for cvs2svn 2.0. I'm basing the reworked cvs_import feature of monotone on that same algorithm. Regards Markus
On Mon, Feb 26, 2007 at 11:07:01AM +0100, Markus Schiltknecht wrote:
> Tom Lane wrote:
> >Yah know, the one bit of these pitches that always sounds like pure
> >snake oil is the claim that they offer some kind of mechanical solution
> >to merge conflicts. AFAICS that has nothing to do with the SCMS in use
> >and everything to do with whether your "diff" command is AI-complete.
>
> You should have said "merge" command. Every tried that? Or kdiff3? Try
> it, you will be surprised!
I'll have to try kdiff3 - but the "merge" command, although it often works,
I strongly dislike when it marks up the lines as "there was a conflict here"
and gives you three files in the directory to choose to start from. This is
far too manual, which invites mistakes. If kdiff3 is more like the ClearCase
graphical merge utility, I would far prefer that. Can you say "I want change
2 followed by change 3" with checkboxes, a live final version to view, and
the ability to manually type or adjust lines in the final version to view?
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
Hi, mark@mark.mielke.cc wrote: > I'll have to try kdiff3 - but the "merge" command, although it often works, > I strongly dislike when it marks up the lines as "there was a conflict here" > and gives you three files in the directory to choose to start from. This is > far too manual, which invites mistakes. Agreed that this is somewhat annoying, but hey, it's a command line tool. How else would you solve displaying conflicts? > If kdiff3 is more like the ClearCase > graphical merge utility, I would far prefer that. Can you say "I want change > 2 followed by change 3" with checkboxes, a live final version to view, and > the ability to manually type or adjust lines in the final version to view? Yup. That's possible. And much much more... ;-) (I don't know the ClearCase tool, so I can't really offer a comparison, sorry.) Others you might want to try: - meld (in python, IMO worse than kdiff3) - xxdiff (I've never really used that one, but other monotone hackers seem to like it as well) Regards Markus
Tom Lane wrote:
> Warren Turkal <wt@penguintechs.org> writes:
>> On Saturday 24 February 2007 23:11, Tom Lane wrote:
>>> I also tend to think that a conversion will be easier in a year or two
>>> than it is today --- the problems noted upthread are certainly a
>>> heads-up that cvs2svn is not yet as robust as one could wish.
>
>> Cvs2svn seems to make as much sense of CVS data as possible. The only real
>> problem I have seen is with regard to the malformed files I mentioned
>> earlier. I haven't seen any other concrete examples.
>
> It was mentioned upthread that Josh has seen repeated problems with his
> conversions. I too would like to see some details about that.
Well the only error I get is if I leave the interfaces/Perl directories
intact. The conversion won't work with those directories.
However as Alvaro has said there are wierd changelog message merges. Now
that may be a configurable thing that I could take a look at.
> One
> thing that I personally would find to be a showstopper for any proposed
> switch is if it fails to maintain our change histories; in particular,
> if it's not still possible to pull an exact copy of any given prior
> release, it'll be no sale.
I agree with this.
> I gather from this thread that svn has by
> far the closest storage model to cvs of any of the available
> alternatives ... so if svn has conversion problems, what's it gonna
> be like with another one?
Well keep in mind there is more than one tool to do the conversion.
cvs2svn is just one of them. We would have to test.
To me a bigger problem , is finding the mistakes before we migrate.
Joshua D. Drake
>
> regards, tom lane
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
>> I imagine the problems are caused by manual mangling of the files in the
>> early days, like the perl5 dir stuff you found.
>
> Hmm, if you only checked using the Trac interface, maybe this is an
> issue with re-creating the SVN repo.
>
> Joshua, do you run "trac-admin /path/to/trac/env resync" after
> rebuilding the repository? (This command would re-sync the trac database
> with the repository.) Otherwise I would certainly expect such issues as
> Alvaro describes.
Oh... Well now, isn't that interesting. I will enable that today :)
Joshua D. Drake
>
> Best Regards
> Michael Paesold
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Warren Turkal wrote: > On Saturday 24 February 2007 16:47, Chad Wagner wrote: > > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v > > head ? ?1.3; > > access; > > symbols > > ? ? ? ? Release-1-6-0:1.1.1.1 > > ? ? ? ? creation:1.1.1.1 > > ? ? ? ? creation:1.1.1; ? ?<<< What the heck happened here? > > locks; strict; > > comment @# @; > > Can a cvs maintainer please correct this file by adding a ";" after the > first "creation" line and removing the second "creation" line? > > wt > -- > Warren Turkal (w00t) > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Warren Turkal wrote: > On Saturday 24 February 2007 16:47, Chad Wagner wrote: > > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v > > head ? ?1.3; > > access; > > symbols > > ? ? ? ? Release-1-6-0:1.1.1.1 > > ? ? ? ? creation:1.1.1.1 > > ? ? ? ? creation:1.1.1; ? ?<<< What the heck happened here? > > locks; strict; > > comment @# @; > > Can a cvs maintainer please correct this file by adding a ";" after the > first "creation" line and removing the second "creation" line? Done. Any other problems? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Warren Turkal wrote: > On Sunday 25 February 2007 23:23, Tom Lane wrote: > > It was mentioned upthread that Josh has seen repeated problems with his > > conversions. > > I am manually inspecting the diff between CVS tag REL_8_1_0 and SVN tag > tags/REL_8_1_0/pgsql, and I am not finding any differences in code short of > the $Id$-type keyword lines. > > However, I am having a problem with encodings in some of the files. How does > cvs handle files with different encodings? For instance, it looks like the > Chinese documentation gets messed up upon svn conversion. I don't know but I do nothing special for the language-specific FAQs in terms of CVS. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Monday 26 February 2007 10:13, Bruce Momjian wrote: > Done. Any other problems? I don't see the fix in the rsync archive. When will it show up there? For reference, the changes were needed in the following files in cvsroot/pgsql/src/interfaces/perl5/Attic: * ApachePg.pl,v * test.pl.newstyle,v * test.pl.oldstyle,v wt -- Warren Turkal (w00t)
On Monday 26 February 2007 08:04, Markus Schiltknecht wrote: > Others you might want to try: > > - meld (in python, IMO worse than kdiff3) > - xxdiff (I've never really used that one, but other monotone hackers > seem to like it as well) A couple more options: * kompare (this one is pretty) * vimdiff wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Monday 26 February 2007 10:13, Bruce Momjian wrote: > > Done. Any other problems? > > I don't see the fix in the rsync archive. When will it show up there? For About an hour. > reference, the changes were needed in the following files in > cvsroot/pgsql/src/interfaces/perl5/Attic: > > * ApachePg.pl,v > * test.pl.newstyle,v > * test.pl.oldstyle,v Fixed now. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: >>> I imagine the problems are caused by manual mangling of the files in the >>> early days, like the perl5 dir stuff you found. >> Hmm, if you only checked using the Trac interface, maybe this is an >> issue with re-creating the SVN repo. >> >> Joshua, do you run "trac-admin /path/to/trac/env resync" after >> rebuilding the repository? (This command would re-sync the trac database >> with the repository.) Otherwise I would certainly expect such issues as >> Alvaro describes. > > Oh... Well now, isn't that interesting. I will enable that today :) O.k. I have done this. You guys can see the results at: http://projects.commandprompt.com/public/pgsql Sincerely, Joshua D. Drake > > Joshua D. Drake > >> Best Regards >> Michael Paesold >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly >> > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
On Monday 26 February 2007 10:13, Bruce Momjian wrote: > Done. Any other problems? Only figuring out the encoding issues with cvs. Thanks, wt -- Warren Turkal (w00t)
On Monday 26 February 2007 10:04, Markus Schiltknecht wrote:
> Hi,
>
> mark@mark.mielke.cc wrote:
> > I'll have to try kdiff3 - but the "merge" command, although it often
> > works, I strongly dislike when it marks up the lines as "there was a
> > conflict here" and gives you three files in the directory to choose to
> > start from. This is far too manual, which invites mistakes.
>
> Agreed that this is somewhat annoying, but hey, it's a command line
> tool. How else would you solve displaying conflicts?
>
> > If kdiff3 is more like the ClearCase
> > graphical merge utility, I would far prefer that. Can you say "I want
> > change 2 followed by change 3" with checkboxes, a live final version to
> > view, and the ability to manually type or adjust lines in the final
> > version to view?
>
> Yup. That's possible. And much much more... ;-) (I don't know the
> ClearCase tool, so I can't really offer a comparison, sorry.)
>
FWIW ClearCase also offers a command line version of its merge tool, where it
shows three columns (a la diff --side-by-side) and allows you to pick which
column you want to merge in (repo, change1, or change2 for example). It's a
nice attempt at doing it on the command line, but the graphical version is so
much better it's worth it to work out remote X and use that instead :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Joshua D. Drake wrote: > Joshua D. Drake wrote: > >>> I imagine the problems are caused by manual mangling of the files in the > >>> early days, like the perl5 dir stuff you found. > >> Hmm, if you only checked using the Trac interface, maybe this is an > >> issue with re-creating the SVN repo. > >> > >> Joshua, do you run "trac-admin /path/to/trac/env resync" after > >> rebuilding the repository? (This command would re-sync the trac database > >> with the repository.) Otherwise I would certainly expect such issues as > >> Alvaro describes. > > > > Oh... Well now, isn't that interesting. I will enable that today :) > > O.k. I have done this. You guys can see the results at: > > http://projects.commandprompt.com/public/pgsql Hmm, this seems to make a lot more sense. Thanks. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Robert Treat wrote: > > FWIW ClearCase also offers a command line version of its merge tool, where it > shows three columns (a la diff --side-by-side) and allows you to pick which > column you want to merge in (repo, change1, or change2 for example). It's a > nice attempt at doing it on the command line, but the graphical version is so > much better it's worth it to work out remote X and use that instead :-) > > If ClearCase is held up as a model SCM system the God help us. True story: a few years back I had a team that where some of them had been using ClearCase, and when they joined our team switched to CVS. A few months later the company made a company-wide decision to standardise on ClearCase. Within weeks I had them begging and pleading with me to be allowed to go back to CVS. cheers andrew
Alvaro Herrera wrote: > Joshua D. Drake wrote: >> Joshua D. Drake wrote: >>>>> I imagine the problems are caused by manual mangling of the files in the >>>>> early days, like the perl5 dir stuff you found. >>>> Hmm, if you only checked using the Trac interface, maybe this is an >>>> issue with re-creating the SVN repo. >>>> >>>> Joshua, do you run "trac-admin /path/to/trac/env resync" after >>>> rebuilding the repository? (This command would re-sync the trac database >>>> with the repository.) Otherwise I would certainly expect such issues as >>>> Alvaro describes. >>> Oh... Well now, isn't that interesting. I will enable that today :) >> O.k. I have done this. You guys can see the results at: >> >> http://projects.commandprompt.com/public/pgsql > > Hmm, this seems to make a lot more sense. Thanks. This is set to happen as part of the conversion as wel. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
On Monday 26 February 2007 14:57, Andrew Dunstan wrote:
> Robert Treat wrote:
> > FWIW ClearCase also offers a command line version of its merge tool,
> > where it shows three columns (a la diff --side-by-side) and allows you to
> > pick which column you want to merge in (repo, change1, or change2 for
> > example). It's a nice attempt at doing it on the command line, but the
> > graphical version is so much better it's worth it to work out remote X
> > and use that instead :-)
>
> If ClearCase is held up as a model SCM system the God help us.
As much as I deride ClearCase in my daily life, I would say ClearCases
graphical merge tools are better than what CVS gives you. That isn't saying
much though...
>
> True story: a few years back I had a team that where some of them had
> been using ClearCase, and when they joined our team switched to CVS. A
> few months later the company made a company-wide decision to standardise
> on ClearCase. Within weeks I had them begging and pleading with me to be
> allowed to go back to CVS.
>
True story: a few years back I was on a team that used CVS. Then our company
made a company-wide decision to standardise on ClearCase. Within weeks we
were begging and pleading to be allowed to go back to CVS. :-)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On Sunday 25 February 2007 01:11, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > Lastly, who really cares? Does it really matter? No. I would much rather
> > Warren (if he has the skills) put some effort into Patch Review.
>
> That's pretty much the bottom line. CVS is not so broken that it's a
> problem for us today. I have no doubt that it could be a problem if we
> had different usage patterns, but we don't.
It's worth keeping in mind that one of the primary reasons we don't have a
different usage pattern is because CVS makes such a thing painful. Given how
much of development is done now, I have a feeling that the community might
well adopt a distributed development model and strongly benefit from it given
a tool that makes it manageable, but CVS will certainly never give us that.
> We have the opportunity to
> wait and see what will emerge in the SCMS competition, and IMHO that's
> what we should do. There are many more-pressing things for us to spend
> time on right now than an SCMS conversion.
>
100% Agreed.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On Monday 26 February 2007 13:50, Robert Treat wrote: > It's worth keeping in mind that one of the primary reasons we don't have a > different usage pattern is because CVS makes such a thing painful. Given > how much of development is done now, I have a feeling that the community > might well adopt a distributed development model and strongly benefit from > it given a tool that makes it manageable, but CVS will certainly never give > us that. Well stated. > > We have the opportunity to > > wait and see what will emerge in the SCMS competition, and IMHO that's > > what we should do. There are many more-pressing things for us to spend > > time on right now than an SCMS conversion. > > 100% Agreed. I think SVN may provide a nicer migration path to the distributed SCMS simply because it supports the atomic changesets. At the very least, it could be a much shorter process than what the current conversion takes (about 3.25 hours on my laptop). Here's ([1]) another interesting bit. [1]http://wiki.services.openoffice.org/wiki/SVNMigration wt -- Warren Turkal (w00t)
On Mon, Feb 26, 2007 at 02:57:03PM -0500, Andrew Dunstan wrote:
> Robert Treat wrote:
> >FWIW ClearCase also offers a command line version of its merge tool, where
> >it shows three columns (a la diff --side-by-side) and allows you to pick
> >which column you want to merge in (repo, change1, or change2 for example).
> >It's a nice attempt at doing it on the command line, but the graphical
> >version is so much better it's worth it to work out remote X and use that
> >instead :-)
> If ClearCase is held up as a model SCM system the God help us.
> True story: a few years back I had a team that where some of them had
> been using ClearCase, and when they joined our team switched to CVS. A
> few months later the company made a company-wide decision to standardise
> on ClearCase. Within weeks I had them begging and pleading with me to be
> allowed to go back to CVS.
This shouldn't be a religious discussion - but I can't let the above go.
Anybody who prefers CVS over ClearCase for any reasons *other* than
financial reasons - doesn't understand SCM.
CVS is pretty close to the bottom for me - below it is SCCS/RCS.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
On Monday 26 February 2007 10:13, Bruce Momjian wrote: > Warren Turkal wrote: > > On Saturday 24 February 2007 16:47, Chad Wagner wrote: > > > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v > > > head ? ?1.3; > > > access; > > > symbols > > > ? ? ? ? Release-1-6-0:1.1.1.1 > > > ? ? ? ? creation:1.1.1.1 > > > ? ? ? ? creation:1.1.1; ? ?<<< What the heck happened here? > > > locks; strict; > > > comment @# @; > > > > Can a cvs maintainer please correct this file by adding a ";" after the > > first "creation" line and removing the second "creation" line? > > Done. Any other problems? This has not been fixed in the rsync repository. Here's one proof for one of the files. wt@braindead:~/projects/postgresql/pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic$ head -n 7 test.pl.newstyle,v head 1.3; access; symbols Release-1-6-0:1.1.1.1 creation:1.1.1.1 creation:1.1.1; locks; strict; wt@braindead:~/projects/postgresql/pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic$ I have attached a patch for the files that needs to be applied within the cvsroot/pgsql/src/interfaces/perl5/Attic directory in the repository. wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Monday 26 February 2007 10:13, Bruce Momjian wrote: > > Warren Turkal wrote: > > > On Saturday 24 February 2007 16:47, Chad Wagner wrote: > > > > head pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle,v > > > > head ? ?1.3; > > > > access; > > > > symbols > > > > ? ? ? ? Release-1-6-0:1.1.1.1 > > > > ? ? ? ? creation:1.1.1.1 > > > > ? ? ? ? creation:1.1.1; ? ?<<< What the heck happened here? > > > > locks; strict; > > > > comment @# @; > > > > > > Can a cvs maintainer please correct this file by adding a ";" after the > > > first "creation" line and removing the second "creation" line? > > > > Done. Any other problems? > > This has not been fixed in the rsync repository. Here's one proof for one of the files. > > wt@braindead:~/projects/postgresql/pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic$ head -n 7 test.pl.newstyle,v > head 1.3; > access; > symbols > Release-1-6-0:1.1.1.1 > creation:1.1.1.1 > creation:1.1.1; > locks; strict; > wt@braindead:~/projects/postgresql/pgsql-cvs/cvsroot/pgsql/src/interfaces/perl5/Attic$ > > I have attached a patch for the files that needs to be applied within > the cvsroot/pgsql/src/interfaces/perl5/Attic directory in the > repository. OK, I definately had added the semicolons, so I am confused why you don't see them. Anyway, I have remove the duplicate 'creation:' lines, so now there is only one line in each file. Let me know how that works. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tuesday 27 February 2007 12:26, Bruce Momjian wrote: > OK, I definately had added the semicolons, so I am confused why you > don't see them. Anyway, I have remove the duplicate 'creation:' lines, > so now there is only one line in each file. Let me know how that works. Everything looks good now. Cvs2svn makes its through where the error originally occurred. Joshua, can you see if your conversion script can do a conversion without deleting the perl5 directory? wt -- Warren Turkal (w00t)
Warren Turkal wrote: > On Tuesday 27 February 2007 12:26, Bruce Momjian wrote: > >> OK, I definately had added the semicolons, so I am confused why you >> don't see them. Anyway, I have remove the duplicate 'creation:' lines, >> so now there is only one line in each file. Let me know how that works. >> > > Everything looks good now. Cvs2svn makes its through where the error > originally occurred. > > Joshua, can you see if your conversion script can do a conversion without > deleting the perl5 directory? > > You know, you can prune what is rsynced. my rsync line looks like this: rsync -avzCH --delete --exclude-from=/home/cvsmirror/pg-exclude anoncvs.postgresql.org::pgsql-cvs /home/cvsmirror/pg and the exclude file has these four lines: /sup/ /CVSROOT/loginfo* /CVSROOT/commitinfo* /CVSROOT/config* cheers andrew
On Tuesday 27 February 2007 13:50, Andrew Dunstan wrote: > You know, you can prune what is rsynced. I am not sure why you brought this up, but yes I did know this. > my rsync line looks like this: > > rsync -avzCH --delete --exclude-from=/home/cvsmirror/pg-exclude > anoncvs.postgresql.org::pgsql-cvs /home/cvsmirror/pg > > and the exclude file has these four lines: > > /sup/ > /CVSROOT/loginfo* > /CVSROOT/commitinfo* > /CVSROOT/config* This setup prunes 1.25MB. Are you suggesting that I prune this from the conversion? wt -- Warren Turkal (w00t)
Warren Turkal wrote:
> On Tuesday 27 February 2007 12:26, Bruce Momjian wrote:
>> OK, I definately had added the semicolons, so I am confused why you
>> don't see them. Anyway, I have remove the duplicate 'creation:' lines,
>> so now there is only one line in each file. Let me know how that works.
>
> Everything looks good now. Cvs2svn makes its through where the error
> originally occurred.
>
> Joshua, can you see if your conversion script can do a conversion without
> deleting the perl5 directory?
Trying now.
>
> wt
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Warren Turkal wrote: > On Tuesday 27 February 2007 12:26, Bruce Momjian wrote: >> OK, I definately had added the semicolons, so I am confused why you >> don't see them. Anyway, I have remove the duplicate 'creation:' lines, >> so now there is only one line in each file. Let me know how that works. > > Everything looks good now. Cvs2svn makes its through where the error > originally occurred. > > Joshua, can you see if your conversion script can do a conversion without > deleting the perl5 directory? My conversion was successfull. You can see here: http://projects.commandprompt.com/public/pgsql > > wt -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
Warren Turkal wrote: > On Tuesday 27 February 2007 13:50, Andrew Dunstan wrote: > >> You know, you can prune what is rsynced. >> > > I am not sure why you brought this up, but yes I did know this. > Well I thought it might be useful to prune that directory you were having trouble with. But we have apparently fixed the problem. > >> my rsync line looks like this: >> >> rsync -avzCH --delete --exclude-from=/home/cvsmirror/pg-exclude >> anoncvs.postgresql.org::pgsql-cvs /home/cvsmirror/pg >> >> and the exclude file has these four lines: >> >> /sup/ >> /CVSROOT/loginfo* >> /CVSROOT/commitinfo* >> /CVSROOT/config* >> > > This setup prunes 1.25MB. > > Are you suggesting that I prune this from the conversion? > > You don't need /sup/ for the conversion, I believe - isn't that just there for cvsup support? Of course, 1.25Mb is fairly small in a 341Mb repo, but every bit helps I guess. cheers andrew
>>>>> "Warren" == Warren Turkal <wt@penguintechs.org> writes: Warren> Is it possible to obtain a mirror of the CVS repository? I use CVSup to locally mirror the repo. They've had the repo available via CVSup for some years now. I use this .cvsup file: ,----(/mirror/CvsUp/Postgresql/pgsql.cvsup) | *default release=cvs host=cvsup.postgresql.org base=/mirror/CvsUp/Postgresql/CVSup | *default prefix=/mirror/CvsUp/Postgresql/cvs delete old use-rel-suffix | *default compress | pgsql `---- (Change the base= and prefix= directories to where you want to store cvsup's working files and the mirror of the repo.) -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Andrew Dunstan wrote: > Jeremy Drake wrote: > > > > rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/ > > > > > > > > The buildfarm howto has somewhat more complete instructions (including > how to adjust the various cvs config files if you need to). I set it up > the other day - took me about 10 minutes. > > http://pgfoundry.org/docman/view.php/1000040/4/PGBuildFarm-HOWTO.txt - > see point 12. I have updated our documenation to mention rsync as a method of pulling the cvs repositiry, and added your URL above for additional information. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/cvs.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v retrieving revision 1.41 diff -c -c -r1.41 cvs.sgml *** doc/src/sgml/cvs.sgml 1 Feb 2007 00:28:16 -0000 1.41 --- doc/src/sgml/cvs.sgml 27 Mar 2007 01:30:14 -0000 *************** *** 27,34 **** </para> <para> ! At least two methods, ! anonymous CVS and <productname>CVSup</productname>, are available to pull the <productname>CVS</productname> code tree from the <productname>PostgreSQL</productname> server to your local machine. </para> --- 27,34 ---- </para> <para> ! At least three methods, anonymous CVS, <productname>rsync</productname>, ! and <productname>CVSup</productname>, are available to pull the <productname>CVS</productname> code tree from the <productname>PostgreSQL</productname> server to your local machine. </para> *************** *** 270,280 **** </para> </sect1> <sect1 id="cvsup"> <title>Getting The Source Via <productname>CVSup</productname></title> <para> ! An alternative to using anonymous CVS for retrieving the <productname>PostgreSQL</productname> source tree is <productname>CVSup</productname>. <productname>CVSup</productname> was developed by --- 270,308 ---- </para> </sect1> + <sect1 id="rsync"> + <title>Getting The Source Via <productname>rsync</productname></title> + + <para> + An alternative to using anonymous CVS for retrieving the + <productname>PostgreSQL</productname> source tree is + <productname>rsync</productname>, an incremental file transfer tool. + A major advantage to using <productname>rsync</productname> is that it + can reliably replicate the <emphasis>entire</emphasis> CVS repository + on your local system, allowing fast local access to <command>cvs</> + operations such as <option>log</option> and <option>diff</option>. + Other advantages include fast synchronization to the + <productname>PostgreSQL</productname> server due to an efficient + streaming transfer protocol which only sends the changes since the last + update. + </para> + + <para> + You can download the CVS repository using this command: + <programlisting> + rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/ + </programlisting> + For full instructions, see the "rsync" section in the + <ulink url="http://pgfoundry.org/docman/view.php/1000040/4/PGBuildFarm-HOWTO.txt"> + pgbuildfarm instructions</ulink>. + </para> + </sect1> + <sect1 id="cvsup"> <title>Getting The Source Via <productname>CVSup</productname></title> <para> ! Another alternative to using anonymous CVS for retrieving the <productname>PostgreSQL</productname> source tree is <productname>CVSup</productname>. <productname>CVSup</productname> was developed by *************** *** 283,298 **** <ulink url="http://www.freebsd.org">FreeBSD project</ulink>. </para> - <para> - A major advantage to using - <productname>CVSup</productname> is that it can reliably - replicate the <emphasis>entire</emphasis> CVS repository on your local system, - allowing fast local access to <command>cvs</> operations such as <option>log</option> - and <option>diff</option>. Other advantages include fast synchronization to - the <productname>PostgreSQL</productname> server due to an efficient - streaming transfer protocol which only sends the changes since the last update. - </para> - <sect2> <title>Preparing A <productname>CVSup</productname> Client System</title> --- 311,316 ----