Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Jordan K. Hubbard wrote: My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. I think that's wise. I'd also recommend people check out Bitkeeper's license before making any final decisions. It's not GPL, BSD, or any other Open Source license. Brian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Wed, 5 May 1999, Brian Behlendorf wrote: On Sat, 1 May 1999, Jordan K. Hubbard wrote: My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. I think that's wise. I'd also recommend people check out Bitkeeper's license before making any final decisions. It's not GPL, BSD, or any other Open Source license. This entire BitKeeper discussion is totally worthless. We're not gonna change. Anyone here want to give up cvsup? Or kick away from a terminal addiction to ctm (and believe me, those ctm'ers are real happily addicted). The answer is no. Face it, it's *possible* that there are better management tools than cvs, but it's for darn sure we can't do better than cvsup/ctm. This discussion merits dropping, at least until someone rewrites cvsup ctm. Don't hold your breath. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
In article pine.bsf.4.10.9905051835560.388-100...@picnic.mat.net, Chuck Robey chu...@picnic.mat.net wrote: This discussion merits dropping, at least until someone rewrites cvsup ctm. Don't hold your breath. I haven't looked at bitkeeper, but I doubt anybody would have to _rewrite_ CVSup. It would just require that a new update method be added to handle whatever their files look like in an intelligent way. Until that was done, it's likely that CVSup's rsync method could handle them reasonbly well. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
In message 19990502015216.a...@keltia.freenix.fr Ollivier Robert writes: : WHat are the improvements compared to Perforce ? After working with Perforce for 9 month at Pluto, I'd have to say it is head and shoulders above CVS. It is a different style of source management, where you have to explicitly open things, but its ability to deal with branches has made it possible to have an extensive set of changes from FreeBSD for pluto boxes and still stay sane. And deal with multiple branches, and deal well with merging. CVSup is still faster at updates that perforce, however... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
In message pine.lnx.4.04.9905011928550.735-100...@feral.com Matthew Jacob writes: : Oh, very well, I'll have to say Perforce isn't that bad- it's just that it : doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole : branch and revision histories.. I've seen many Tk tools that do this. There is also a web interface as well. : It doesn't have a 3-way filemerge tool (I : still fire up teamware (what NSElite became) to do heavy merging and use : the automerge feature)... That is true. : Perforce *does* have the disparate release : stream feature, but I have found it somewhat difficult to use. Perhaps if : I'd actually had the depot locally I'd feel more at home with it Once you get use to it, it is much easier to use than CVS. I have my own branch for kernel changes that I'm in the middle of, and merging them is as simple as p4 integrate newsrc/sys/... src/sys/... p4 resolve And I can also merge the changes to my src/sys/... tree back into newsrc/sys/... at any time with p4 integrate src/sys/... newsrc/sys/... p4 resolve I'd go insane without it. Or more likely people at work would be more upset with my tendancy to checkin early and often to make sure all the places I work on stuff are in sync. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
RW == Robert Watson rob...@cyrus.watson.org writes: RW So will bitkeeper provide a nice interface for migrating code RW from an existing and well-established CVS repository to RW whatever they use? I've looked at bitkeeper and wonder what exactly are it's advantages over CVS. It's model looks very much geared towards the fragmented way Linux is developed, offering no advantages for more centralized models such as FreeBSD or most commercial internal environments. In the Linux environment the 'patch' is everything, and the kernel looks like a big pile of 'patches' to me. Thus in bitkeeper generating these patch sets (containing history log messages) to submit from one repository to another is important, because people exchange patches all the time. The other thing is some graphic tools (written in tcl/tk) but there are also some of such GUI layers for CVS, though they've never become very popular because the command line (combined with UNIX pipes std. commands, filters) cannot be beaten for this type of work IMO. I'd suggest to at least wait a (long) while to see how it is developing. At the moment I see absolutely no advantage for more centralized development models. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know p...@xs4all.nl | the Netherlands| what I'm doing. ---+-+-- Running FreeBSD-current UNIX. See http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Jacob wrote... Oh, very well, I'll have to say Perforce isn't that bad- it's just that it doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole branch and revision histories.. I know there's a reasonable web-based tool that lets you look at revision histories for files, trees, whatever. There's also a nice tcl/tk tool that allows you to do merge files from a gui interface. It doesn't have a 3-way filemerge tool (I still fire up teamware (what NSElite became) to do heavy merging and use the automerge feature)... Perforce *does* have the disparate release stream feature, but I have found it somewhat difficult to use. Perhaps if I'd actually had the depot locally I'd feel more at home with it What do you mean by 3-way merge? I've got one souce tree under perforce that is an amalgamtion of 5 source trees. Right now, I'm actively keeping it in sync with two separate source trees. And this is a non-trivial number of files -- each of the trees in question is at least a full FreeBSD source tree. Perforce's merging tools work pretty well, and have enabled me to do some branching and merging that would probably drive even a seasoned CVS user nuts. Here's how I generally merge things from two branches into a combined branch: p4 integrate -b branch1-to-combined-branch [ The -b argument specifies the branch mapping, which basically is the source and destination trees ] p4 resolve -as [ This tells perforce to resolve the merge, and accept safe changes. Safe changes are changes to files that have changed in the source or destination branches, but not both. ] p4 resolve [ This picks up the files that weren't automatically merged in the last step. For most files, perforce is able to merge things adequately, but when it can't, you have to go in and edit things manually, or specify whether you want to keep the source or destination branch version of the file. ] p4 submit [ Write a change description, edit the list of files to submit, and then check things in. ] You then repeat the same process for the second branch merge, except that in the first step, you'd use a different branch mapping. It's also pretty easy to merge things in the opposite direction. You can also do nifty things like only merge certain files from one branch to another, or only merge certain changes from one branch to another. It's possible, for instance, to merge revisions 4, 5, 7, and 9 of a file, but not 6 or 8. It's also possible to merge certain changelists from one branch to another, instead of doing a blanket merge. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Matthew Dillon wrote: # #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS.
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
# #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS. From what I gather (and I could very well be wrong), but I think BitKeeper is somewhat based on SCCS. I'm not advocating that we ditch CVS either, just that BitKeeper may not be as new and fresh as some would like us to believe. Looks like an old friend (or nemisis) dressed in a new set of rags. :) No, not really. Larry's hostile to RCS because of it's lack of checksum. I've asked him about it a couple of times and he's not really excited about an RCS bottom end. It could be done if you insisted on it (I mean, it's GPL'd code, right?) but it's not something he would support. Bitkeeper is a substantial improvement over CVS and Perforce. It's really a nice piece of work done by somebody who *really* knows his stuff. Remember that Larry saved Sun from complete disaster by inventing NSElite (which Bitkeeper is emphatically a granchild of) in time to keep 1000 engineers from rising up and tearing Eric Schmidt to threads over his insistence that The Sun/SVR4 merge *SHALL* use NSE and the [ broken ] translucent filesystem if we're here until the year 2000 doing it!. Personally, I'm happy with CVS if you have a model a single main stream of development. It's a disaster when you have to maintain separate development clusters. And very few other packages really do any kind of job of this either. Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
So will bitkeeper provide a nice interface for migrating code from an existing and well-established CVS repository to whatever they use? I'm quite happy to allow them to test bitkeeper in a production environment before using it in one myself, needless to say. :) On Sat, 1 May 1999, Matthew Jacob wrote: # #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS. From what I gather (and I could very well be wrong), but I think BitKeeper is somewhat based on SCCS. I'm not advocating that we ditch CVS either, just that BitKeeper may not be as new and fresh as some would like us to believe. Looks like an old friend (or nemisis) dressed in a new set of rags. :) No, not really. Larry's hostile to RCS because of it's lack of checksum. I've asked him about it a couple of times and he's not really excited about an RCS bottom end. It could be done if you insisted on it (I mean, it's GPL'd code, right?) but it's not something he would support. Bitkeeper is a substantial improvement over CVS and Perforce. It's really a nice piece of work done by somebody who *really* knows his stuff. Remember that Larry saved Sun from complete disaster by inventing NSElite (which Bitkeeper is emphatically a granchild of) in time to keep 1000 engineers from rising up and tearing Eric Schmidt to threads over his insistence that The Sun/SVR4 merge *SHALL* use NSE and the [ broken ] translucent filesystem if we're here until the year 2000 doing it!. Personally, I'm happy with CVS if you have a model a single main stream of development. It's a disaster when you have to maintain separate development clusters. And very few other packages really do any kind of job of this either. Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
As I understand it, BitKeeper is indeed based on SCCS, and is a superset of it. The performance hit of SCCS has been solved. There are several significant commercial users of BitKeeper waiting for the first production release, and Larry McVoy seems to be a bit of a maniac when it comes to things being production stable. He said that a CVS-BitKeeper conversion tool is not far off. I'm mostly interested in the lines of development features, the ability to check in various revisions of my *local* work, the ability to apply a patch set as an atomic unit, and several of the GUI tools. H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
So will bitkeeper provide a nice interface for migrating code from an existing and well-established CVS repository to whatever they use? They have tools for RCS to SCCS- I dunno about CVS tho... I'm quite happy to allow them to test bitkeeper in a production environment before using it in one myself, needless to say. :) fair enuff To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
As I understand it, BitKeeper is indeed based on SCCS, and is a superset of it. The performance hit of SCCS has been solved. There are several significant commercial users of BitKeeper waiting for the first production release, and Larry McVoy seems to be a bit of a maniac when it comes to things being production stable. He said that a CVS-BitKeeper conversion tool is not far off. Cool! I'm mostly interested in the lines of development features, the ability to check in various revisions of my *local* work, the ability to apply a patch set as an atomic unit, and several of the GUI tools. Amen to that To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. I think this all fails to address the distribution problem, however. Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb, all interfaces in extremely common use today? It's not just enough to say something will be worked out as an answer either, not when contemplating a move which will remove services currently in heavy operational use. Think about it. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. I think this all fails to address the distribution problem, however. Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb, all interfaces in extremely common use today? It's not just enough to say something will be worked out as an answer either, not when contemplating a move which will remove services currently in heavy operational use. Think about it. :) I'll try, but it hurts my head (Why, Ale, man! Ale's the stuff to drink, for them whom it hurts to think!...) I wasn't suggesting that we jump..I would like to see a plan. I believe BitKeeper and other tools are a good set of tools for the next 5-10 years for *development*. *Distribution* is a separate issue. Again, CVS is a fine tool for distribution and asymmetric (biased toward a higher level of outbound source changes) development. It all depends on what we want. And I'll have to admit that distribution of binaries source is not something that always is on the top of my list (well, *I'm* not working for a software distribution company...:-)).. My comment about 'think about it' is that if Linux gets it's chaotic source non-management corrected and is able to successfully coordinate all the relatively anarchic and free running clock different groups then the 'predictability and reproducibility' concerns of commercial buyers are closer to being met (which is silly because of how really chaotic internal company release spasms are, SGI being a notorious example- but there it is). If FreeBSD (and NetBSD and OpenBSD) are to continue the way it is now, CVS is probably a good enough tool. However, if you incorporate something like BitKeeper into the picture, then it actually becomes technically more feasible to even begin *considering* a *BSD coordination- you start to have to toolset that can manage large amounts of code that is mostly alike but differs in enough ways to be too hard to just merge this week. But then again you might say, Pshaw- Matt's been smokin' some serious rope again. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Well, I'm not philosophically opposed to a clearly superior solution, I simply don't want to see us make any moves which involve so many messy trade-offs that we end up wasting more time embroiled in debate than we save with the new tool. My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Well, I'm not philosophically opposed to a clearly superior solution, I simply don't want to see us make any moves which involve so many messy trade-offs that we end up wasting more time embroiled in debate than we save with the new tool. My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. Well, that's fine too, then... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
According to Matthew Jacob: Bitkeeper is a substantial improvement over CVS and Perforce. It's really WHat are the improvements compared to Perforce ? I've begun looking at it and if we forgot the Open Source argument (one that the FreeBSD project can't forget), it is really a very nice SCM. They even give free licenses to people writing/maintaining free software. I know, I just got mine. User name: roberto Client name: dotfiles Client root: /users/staff/roberto Current directory: /tmp Client address: 193.56.58.65:2838 Server address: keltia.freenix.fr:1666 Server root: /work/p4home Server version: P4D/FREEBSD/99.1/10314 (1999/03/31) Server license: Robert Ollivier robe...@eurocontrol.fr 10 users on freebsd (support ends 2000/04/26) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
According to Harlan Stenn: I'm mostly interested in the lines of development features, the ability to check in various revisions of my *local* work, the ability to apply a patch set as an atomic unit, and several of the GUI tools. Perforce has all that. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Oh, very well, I'll have to say Perforce isn't that bad- it's just that it doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole branch and revision histories.. It doesn't have a 3-way filemerge tool (I still fire up teamware (what NSElite became) to do heavy merging and use the automerge feature)... Perforce *does* have the disparate release stream feature, but I have found it somewhat difficult to use. Perhaps if I'd actually had the depot locally I'd feel more at home with it Bitkeeper is a substantial improvement over CVS and Perforce. It's really WHat are the improvements compared to Perforce ? I've begun looking at it and if we forgot the Open Source argument (one that the FreeBSD project can't forget), it is really a very nice SCM. They even give free licenses to people writing/maintaining free software. I know, I just got mine. User name: roberto Client name: dotfiles Client root: /users/staff/roberto Current directory: /tmp Client address: 193.56.58.65:2838 Server address: keltia.freenix.fr:1666 Server root: /work/p4home Server version: P4D/FREEBSD/99.1/10314 (1999/03/31) Server license: Robert Ollivier robe...@eurocontrol.fr 10 users on freebsd (support ends 2000/04/26) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
The folks who did BitKeeper have a compare/contrast section in their web page that talks about BitKeeper vs. CVS and Perforce. http://www.bitkeeper.com I'm running CVS at several places, and I'm going to try BitKeeper for a couple of projects. H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
