Re: About the OpenBSD repository
On Fri, Jun 26, 2009 at 2:23 PM, Nidon...@foxserver.be wrote: Come on, it is fucking inefficient. The way it checks out *empty directories* and then garbage-collects them at the end of an update is beyond stupid. Not that i particularly care; but isn't git incapable of checking out empty directories? Besides that, it is perfectly possible to use git yourself privately alongside whatever the project is using; so I don't really get what the problem is. Git tracks *contents* not files themselves. Empty directories don't have content so they are ignored by git. I too would like to see some nice BSD-licensed DVCS on OpenBSD. I think that would be a major project to accomplish and I think I'd rather see such energy go into developing OpenBSD, not developing the development process :) Timo
Re: About the OpenBSD repository
On Tue, Jun 23, 2009 at 07:39:41AM -0500, Marco Peereboom wrote: Manure alert! On Tue, Jun 23, 2009 at 02:16:39PM +0200, Hannah Schroeter wrote: Hi! On Mon, Jun 22, 2009 at 02:11:21PM -0500, Marco Peereboom wrote: What is wrong with CVS? And no I am not talking about the hypotheticals and some bugs that exist in the current code (that can also be easily worked around). - It's *slow* (once you've seen git's speed, both cvs and svn are snails against it; hg and bzr might perhaps compare with it, though). It isn't slow. I can check out a tree in a minute. Here is a nickel kid go buy yourself some real disks. Come on, it is fucking inefficient. The way it checks out *empty directories* and then garbage-collects them at the end of an update is beyond stupid.
Re: About the OpenBSD repository
On Tue, Jun 23, 2009 at 02:17:30PM +0200, Hannah Schroeter wrote: Hi! On Mon, Jun 22, 2009 at 10:16:12PM +0100, Anil Madhavapeddy wrote: Pretty much every single new revision control system can import/export from CVS, so use whatever you want... I tried git cvsimport on OpenBSD's tree and it failed, alas. cvs2svn doesn't grok some peculiarities of OpenBSD's tree either. Sort of pointless to add more fuel to this discussion, but here it goes: None of the cvs importers (known to me) can import the src tree. They all parse the output of cvs log/rlog. That doesn't work because cvs doesn't escape anything but what is necessary for its rcs file structure (@ and stuff) Various places in the src tree have commit messages that contain cvs log output. panic(I'm confused! Halp!). Migrating this is some work, likely involves writing your own rcs parser... Yes there is sed. If you have too much time in your hands and an amd64 (because it needs to handle 1G+ datasets), you may be able to make it work. However everyone i've asked gave up. Next step would be writing open(hg|git) with a license for real men (:P) Kind regards, Hannah.
Re: About the OpenBSD repository
Come on, it is fucking inefficient. The way it checks out *empty directories* and then garbage-collects them at the end of an update is beyond stupid. Not that i particularly care; but isn't git incapable of checking out empty directories? Besides that, it is perfectly possible to use git yourself privately alongside whatever the project is using; so I don't really get what the problem is.
Re: About the OpenBSD repository
There's also ample room for improvements in some of the algorithms cvs currently use. It positively SUCKS at merging stuff. It can't even work with its own keywords properly. I no longer count the number of times I've had a *conflict* after a merge on code I committed myself in another tree, just because cvs is stupid enough to not recognize $OpenBSD: 1.1$ vs. $OpenBSD: 1.3$ And we all know that branch-merging doesn't actually work. The process to merge branches I used in the past was: - create the diff I want to use - checkout a pristine tree and apply the diff by hand. - checkout the tree I'm going to work on. - use the cvs merge/commit operations. - wipe out the work tree - cvs check out the result - compare against what I would like to have. - fix all the stupid mistakes cvs did. YES, it is THAT bad. I've done enough gcc merges to know. Ask matthieu@ as well, each xorg merge shows traces of those issues as well. In particular, cvs does resurrect files I explicitly deleted on the branch, for absolutely no good reason. The source code from GNU cvs is FULL of highly special cases that make absolutely NO SENSE in general, are totally non-documented, and were obviously hacked in because some stupid guy needed it for his own very special project with its own hackish rules. I definitely have high hopes opencvs will be better in that regard eventually. I don't care all that much for speed, but hey, when I see a version control system do dumb mistakes it has no business doing, and needing me to fix obvious stuff like that... there's MASSIVE room for improvements.
Re: About the OpenBSD repository
On 06/23/09 18:58, Theo de Raadt wrote: Blah blah blah blah That is clearly self describing... You just like listening to yourself talk. Shut up. Pooh, pooh Mr Not Invented Here and We didn't learned that in our BSD Kindergarten. Hannah is clearly just informative (as always!) and believes, with good reason and first hand experience, in what she proposes. +++chefren
Re: About the OpenBSD repository
I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? Discussed much in archives, try also to search for opencvs, and i think you will hit some information of why cvs. (i think!) You seem to make the assumption that _everything_ else is better than CVS. This may be your opinion, but that's all it is. I can't see any assumption of that? Well, I suppose it is better than RCS or SCCS, and in some small ways, CVS even did things right that SVN gets wrong (namely, tags). But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :) Flamer! :) http://www.openbsd.org/why-cvs.html Because none of the above mentioned will allow for 70+ developers to update ~1.2GB/~140,000 files of source code, allow anonymous checkouts, has an available web based interface and interfaces with ssh. Instead though non atomic commits, expensive branches and almost 20 years of work arounds are utilized. SVN can definitely do this, lost of large project are using it. Ealier posts mentions distributed systems like Mercurial, and GIT. They can definitely also do it. it has webbased frontend, anonymous checkouts. interfaces with ssh, what do you mean, SVN does that. Most systems can send commands via ssh. so that should be no reason to not choose it. Or is there some specific detail I am missing? Mercurial is used by netbeans team, opensolaris, xen. Mozilla? Im sure that is quite large codebases. Git is used by linux kernel devs, and that has a ridiclous amount of code. Comparable to the openbsd source tree. I have used CVS, SVN, SVK(svn with repository mirroed locally), git, mercurial sourcesafe. RCS (still use it, sometimes together with one of the other SCM systems) I use mercurial right now for my own projects, having the repository locally makes it much easier when travelling etc(offline situations), i think. Could as well be Git. (i assumed you were on the look out for something to use yourself?) mic
Re: About the OpenBSD repository
Mic J michael.cogn...@gmail.com writes: But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :) Mercurial and Git are crap. Because none of the above mentioned will allow for 70+ developers to update ~1.2GB/~140,000 files of source code, allow anonymous checkouts, has an available web based interface and interfaces with ssh. Instead though non atomic commits, expensive branches and almost 20 years of work arounds are utilized. SVN can definitely do this, lost of large project are using it. From two hours ago at work: $ svn cleanup svn: Working copy 'lib/common' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) $ svn cleanup lib/common svn: Working copy 'lib/common' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) $ svn help cleanup cleanup: Recursively clean up the working copy, removing locks, resuming unfinished operations, etc. usage: cleanup [PATH...] Valid options: --diff3-cmd ARG : use ARG as merge command Global options: --username ARG : specify a username ARG --password ARG : specify a password ARG --no-auth-cache : do not cache authentication tokens --non-interactive: do no interactive prompting --config-dir ARG : read user configuration files from directory ARG $ ok. And of course the atomic commits are bullshit because even though the commit failed and left a corrupted local checkout that I had to manually nuke and then copy the right files over, it still did commit some parts of my work. At least it didn't corrupt the database like it did a year ago where we lost two days of work because the only solution was to restore from backup. Now, only the tree was broken until I could figure out wtf it was doing. At least we know and understand the bugs and limitations of cvs. You don't like it - don't use it, but god sake, stop telling people what your favourite color is and why it should be their favourite color too. //art
Re: About the OpenBSD repository
On Mon, Jun 22, 2009 at 07:13:51PM -0700, Mike Swanson wrote: Paul M wrote: On 23/06/2009, at 6:44 AM, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? You seem to make the assumption that _everything_ else is better than CVS. This may be your opinion, but that's all it is. paulm Well, I suppose it is better than RCS or SCCS, and in some small ways, CVS even did things right that SVN gets wrong (namely, tags). But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :) To assume that it is not superiour in the particular application to which it is being put is also ridiculous. Having 1000 extra features you don't use and will never use is not an advantage. Ken
Re: About the OpenBSD repository
Hi! On Mon, Jun 22, 2009 at 10:16:12PM +0100, Anil Madhavapeddy wrote: Pretty much every single new revision control system can import/export from CVS, so use whatever you want... I tried git cvsimport on OpenBSD's tree and it failed, alas. cvs2svn doesn't grok some peculiarities of OpenBSD's tree either. Kind regards, Hannah.
Re: About the OpenBSD repository
Hi! On Mon, Jun 22, 2009 at 02:11:21PM -0500, Marco Peereboom wrote: What is wrong with CVS? And no I am not talking about the hypotheticals and some bugs that exist in the current code (that can also be easily worked around). - It's *slow* (once you've seen git's speed, both cvs and svn are snails against it; hg and bzr might perhaps compare with it, though). - How often you've seen people (devs with commit access) do development without committing it because it wasn't ready for prime time, then committing it in chunks that can't be grokked any more because they have accumulated for months or even over a year? You can't have off-site development branches in centralized version control systems. You *can* with distributed ones. You can merge them *and keep history* later somewhat easier than without having distributed vcs abilities. - Non-committers can keep track of their local modifications in a more structured ways (because they can too have local inofficial branches) with a distributed vcs. So submission of patches can be more structured. - Did I mention: most current dvcs are *fast*. And you can usually mirror the repo (just as cvsync does, just you don't need an addon tool for it). - The history is still kept at a file level. While we see commit mails in a changeset form, if I want to look at what has been changed, I have to check per file (first cvs log, then cvs diff, or the equivalent thereof on the web). Even with svn I can do so with *one* svn log, then svn diff for the *whole* commit. With git I can do so with *one* git log -p for the whole commit (no further diff operation). - Disconnected operation. With cvs I can do nearly nothing (related to version control, that is) offline. (Devs working on the plane, anyone?) With svn I can just check the status and the diff against the *current* pristine version. With git, for example, I can inspect the *whole* history up to now, and I can create new structured history from now. The only thing I can't do offline is get new history from others (upstream or other devs or other users) or export my new history (to an official repository or peer-to-peer to other users/devs). - Sometimes even little features like git stash (put away uncommitted stuff for a moment in order to do something else, but ready to be retrieved again) or git add -i (prepare to only *selectively* commit changes) come handy. - Oh, when I notice a mistake immediately after the fact, I can (a)mend it with git up to the moment I exported my history! Less of oops I committed this port to the wrong place. Of course without having to completely *manually* hacking the repository tree. - For versioning local things (like /etc), I don't need to dedicate a completely different place for the repository. One .git directory is good enough for everything (where cvs needs a CVS/ directory for every directory in the working tree *and* a separate repository directory hierarchy). Same gripe about svn, btw (a .svn in every directory in the working directory, even more bloated than cvs, and a separate repository tree, also quite fat). I have used just about all versioning systems, including ones that have the price tag of islands in the pacific, and ultimately they all suck in their special ways. CVS works well-enough. I beg to differ. I was somewhat relieved when we switched from cvs to svn at work (for our work projects). svn does suck, too, of course. For example, non-first-class tags and branches, big overhead in its working copies, and it's slow too, but at least it has real versioning across directory *trees*, so operations like ... log and ... diff actually make sense, you can actually look at the history in a tree/changeset granularity. Nowadays I still scorn svn here. But at the same time, I dislike cvs more. cvs up -APd on /usr/src, or /usr/ports is just *so slow* even with a *local* (cvsync) mirror. Even with async,noatime mounts and export CVSREADONLYFS=1. cvs commit is slow (and non-atomic!). Nowadays I use git-svn to make working with the company's svn service a bit more bearable. And I profit of the ability to keep local branches, to exporting new history at a time when *I* see fit, etc. Kind regards, Hannah.
Re: About the OpenBSD repository
Hi! On Mon, Jun 22, 2009 at 09:58:04PM -0500, Eugene Prodeguene wrote: [...] http://www.openbsd.org/why-cvs.html Because none of the above mentioned will allow for 70+ developers to update ~1.2GB/~140,000 files of source code, allow anonymous checkouts, has an available web based interface and interfaces with ssh. Now, that page uses outdated comparisons. Ok, cvs works better than sup... Wow. sup is such a current comparison ;-) Now, git allows even more efficient updates and checkins, both authenticated via ssh, and anonymously. For anonymous readonly access you don't need ssh, because git uses sha1 hashes for everything. (Ok, the use of sha1 becomes more and more debatable, of course.) You can even gpg sign tags if you like (but unsigned tags are also available, and tags and branches are *cheap*, no churning through thousands of files for creating a tag or branch!). Of course it has a standard web interface, too. And it's more convenient, because you can look at changes in changesets instead of spreading *one* commit over all the files touched as if it were independent changes. git is very efficient both for deep history and quite large trees. Just as an example (other dvcs seem to perform well too on those lines of comparison). Of course svn offers similar features too (web interface, of course, svn via ssh or own service or https/dav). It has some drawbacks (I'm not a great fan of it anymore): non-first-class tags/branches, bloated working-directory format, bigger repository (IIRC git has one of the most compact repository packing algorithms). [...] Kind regards, Hannah.
Re: About the OpenBSD repository
Hi! On Tue, Jun 23, 2009 at 12:48:33PM +0200, Artur Grabowski wrote: Mic J michael.cogn...@gmail.com writes: But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :) Mercurial and Git are crap. Why do you think so? My experiences with git are quite good. [...] From two hours ago at work: $ svn cleanup svn: Working copy 'lib/common' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) $ svn cleanup lib/common svn: Working copy 'lib/common' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Never happened for me. ok. And of course the atomic commits are bullshit because even though the commit failed and left a corrupted local checkout that I had to manually nuke and then copy the right files over, it still did commit some parts of my work. At least it didn't corrupt the database like it did a year ago where we lost two days of work because the only solution was to restore from backup. Now, only the tree was broken until I could figure out wtf it was doing. Never happened for me. That old Berkeley db stuff was shit, yes. fsfs seems to do okish (though it's still bloated compared to git *g*). But I didn't see half-commits. And at our companies we *did* switch to svn at Berkeley db times. And I do know some points where svn sucks. At least we know and understand the bugs and limitations of cvs. You don't like it - don't use it, but god sake, stop telling people what your favourite color is and why it should be their favourite color too. Of course I respect the right of the devs (and finally Theo) to choose. Still I wanted to put forth what *I* (not you or other devs!) like about other systems and what I came to dislike about cvs over the years (and that me, who first was one pressuring to introduce cvs here at work in the first place; then cvs was much better than no version control at all, and then there were definitely no better alternatives available, and first I wasn't really fond of the decision to switch to svn). Kind regards, Hannah.
Re: About the OpenBSD repository
Hi! On Tue, Jun 23, 2009 at 08:11:42AM -0400, Kenneth R Westerback wrote: [...] To assume that it is not superiour in the particular application to which it is being put is also ridiculous. Having 1000 extra features you don't use and will never use is not an advantage. If one hasn't tried it out, it's difficult to assume one would never use features like disconnected operations (devs on planes), local/inofficial branches (devs working on new features that aren't ready for prime time yet; I'm committing this, disconnected from the build, so others can work on it wouldn't be completely necessary either, for example, if one could share experimental branches using a dvcs). But even for traditional operations... I'm for example hooked on the mere speed of git compared to svn or cvs even for a not so big tree like a private web project. And even for that I use the fact that both repositories are equals. At home, I commit to the local repository on the home box. Elsewhere I might remote-login to a leased server where another repository lies (and where also the http server is, using a 3rd copy which always is on the public branch, while the other repositories also have other branches). Or I might temporarily clone the repository from the leased server, work locally (perhaps doing more than one revision), then push the work (in one hunk!) back to the leased server and publish (i.e. update the public branch to the http server's directory). Especially over slow lines, definitely an advantage over having only one central cvs/svn repo on the leased server and only working copies on the other boxes. Local operations are *fast* (e.g. switching from one branch to another with git checkout, compared to cvs up -r... for switching the branch or svn switch or ...). Ken Kind regards, Hannah.
Re: About the OpenBSD repository
Manure alert! On Tue, Jun 23, 2009 at 02:16:39PM +0200, Hannah Schroeter wrote: Hi! On Mon, Jun 22, 2009 at 02:11:21PM -0500, Marco Peereboom wrote: What is wrong with CVS? And no I am not talking about the hypotheticals and some bugs that exist in the current code (that can also be easily worked around). - It's *slow* (once you've seen git's speed, both cvs and svn are snails against it; hg and bzr might perhaps compare with it, though). It isn't slow. I can check out a tree in a minute. Here is a nickel kid go buy yourself some real disks. - How often you've seen people (devs with commit access) do development without committing it because it wasn't ready for prime time, then committing it in chunks that can't be grokked any more because they have accumulated for months or even over a year? You can't have off-site development branches in centralized version control systems. You *can* with distributed ones. You can merge them *and keep history* later somewhat easier than without having distributed vcs abilities. Oh I guess the cvsync tree I have on my laptop and all my development trees don't count. This is all uninteresting blabbing of someone who doesn't know how to use cvs. - Non-committers can keep track of their local modifications in a more structured ways (because they can too have local inofficial branches) with a distributed vcs. So submission of patches can be more structured. see previous. - Did I mention: most current dvcs are *fast*. And you can usually mirror the repo (just as cvsync does, just you don't need an addon tool for it). *yawn* - The history is still kept at a file level. While we see commit mails in a changeset form, if I want to look at what has been changed, I have to check per file (first cvs log, then cvs diff, or the equivalent thereof on the web). Even with svn I can do so with *one* svn log, then svn diff for the *whole* commit. With git I can do so with *one* git log -p for the whole commit (no further diff operation). Sure you found a nice feature but hardly killer or worth any downtime and relearning of some other retarded system that is full of unknown bugs. - Disconnected operation. With cvs I can do nearly nothing (related to version control, that is) offline. (Devs working on the plane, anyone?) With svn I can just check the status and the diff against the *current* pristine version. With git, for example, I can inspect the *whole* history up to now, and I can create new structured history from now. The only thing I can't do offline is get new history from others (upstream or other devs or other users) or export my new history (to an official repository or peer-to-peer to other users/devs). I do this all the time. You have no idea about cvs. - Sometimes even little features like git stash (put away uncommitted stuff for a moment in order to do something else, but ready to be retrieved again) or git add -i (prepare to only *selectively* commit changes) come handy. I would never remember that. Not useful. - Oh, when I notice a mistake immediately after the fact, I can (a)mend it with git up to the moment I exported my history! Less of oops I committed this port to the wrong place. Of course without having to completely *manually* hacking the repository tree. Lear to commit with a proper procedure and you don't have to rely on hacks. - For versioning local things (like /etc), I don't need to dedicate a completely different place for the repository. One .git directory is good enough for everything (where cvs needs a CVS/ directory for every directory in the working tree *and* a separate repository directory hierarchy). Same gripe about svn, btw (a .svn in every directory in the working directory, even more bloated than cvs, and a separate repository tree, also quite fat). Boooring I have used just about all versioning systems, including ones that have the price tag of islands in the pacific, and ultimately they all suck in their special ways. CVS works well-enough. I beg to differ. I was somewhat relieved when we switched from cvs to svn at work (for our work projects). svn does suck, too, of course. For example, non-first-class tags and branches, big overhead in its working copies, and it's slow too, but at least it has real versioning across directory *trees*, so operations like ... log and ... diff actually make sense, you can actually look at the history in a tree/changeset granularity. Now if it wouldn't shit itself all the time... Nowadays I still scorn svn here. But at the same time, I dislike cvs more. cvs up -APd on /usr/src, or /usr/ports is just *so slow* even with a *local* (cvsync) mirror. Even with async,noatime mounts and export CVSREADONLYFS=1. cvs commit is slow (and non-atomic!). Coordinate your commits; problem solved. These are the things people point at
Re: About the OpenBSD repository
Hi! On Tue, Jun 23, 2009 at 07:39:41AM -0500, Marco Peereboom wrote: Manure alert! On Tue, Jun 23, 2009 at 02:16:39PM +0200, Hannah Schroeter wrote: On Mon, Jun 22, 2009 at 02:11:21PM -0500, Marco Peereboom wrote: What is wrong with CVS? And no I am not talking about the hypotheticals and some bugs that exist in the current code (that can also be easily worked around). - It's *slow* (once you've seen git's speed, both cvs and svn are snails against it; hg and bzr might perhaps compare with it, though). It isn't slow. I can check out a tree in a minute. Here is a nickel kid go buy yourself some real disks. Ok, just checked with git: Linux-2.6 tree. Update after about one month: I did by purpose separate the update into two parts: git fetch, then git merge instead of the usual git pull, so I can measure timing separately. git fetch origin (roughly equivalent to cvsync): about one minute, received a bit more than 17 MiB of data, roughly 8,5k changes (not files, but tree changes/commits) from the last update. git merge origin/master (roughly equivalent to cvs up with appropriate options, up-to-date-check/check for conflicts, reset the local branch to the remote branch and checkout files): 7738 files touched, 1m51 real time. That's with a normal local desktop style disk, not with a high end raid system or something like that. That is, a disk where it takes *several* minutes to cvs up, and where it takes *several* minutes to check for changes even after less time. (time git status, i.e. check for local changes: less than 10 seconds on the same tree). - How often you've seen people (devs with commit access) do development without committing it because it wasn't ready for prime time, then committing it in chunks that can't be grokked any more because they have accumulated for months or even over a year? You can't have off-site development branches in centralized version control systems. You *can* with distributed ones. You can merge them *and keep history* later somewhat easier than without having distributed vcs abilities. Oh I guess the cvsync tree I have on my laptop and all my development trees don't count. This is all uninteresting blabbing of someone who doesn't know how to use cvs. I have a cvsync tree too. But your local trees etc. aren't versioned the same way as they were with a dvcs. You can't commit to a cvsync tree the same way as you can commit locally with a dvcs. (Because your local commits would be overwritten on the next cvsync call.) You can, of course, have several local checkouts from the local cvsync tree with non-versioned, non-committed modifications. But if you have *one* strand of local development going on where one step depends on the next one, you can't version those steps in a structured *tool-supported* way with a centralized version control system. (You can do so without tool support if you copy out every version/commit to a separate directory tree, which takes more time and space than a local commit in a dvcs. That's about the same degree of organization as it was when one had foo.c.version1, foo.c.version2 in times when our company didn't use version control at all.) - Non-committers can keep track of their local modifications in a more structured ways (because they can too have local inofficial branches) with a distributed vcs. So submission of patches can be more structured. see previous. - Did I mention: most current dvcs are *fast*. And you can usually mirror the repo (just as cvsync does, just you don't need an addon tool for it). *yawn* - The history is still kept at a file level. While we see commit mails in a changeset form, if I want to look at what has been changed, I have to check per file (first cvs log, then cvs diff, or the equivalent thereof on the web). Even with svn I can do so with *one* svn log, then svn diff for the *whole* commit. With git I can do so with *one* git log -p for the whole commit (no further diff operation). Sure you found a nice feature but hardly killer or worth any downtime and relearning of some other retarded system that is full of unknown bugs. My experience is different. I deferred that learning curve for some time, too, when friends already were telling of their (in their experience, of course) good experiences with dvcs. Later I took some spare time for that. Now even some co-workers sometimes moan about some lacks of the company's centralized-only version control. I haven't really, yet, stumbled over annoying problems of git, btw. While OpenBSD committers seem to do so over problems of cvs, if I see things right on source-chan...@. - Disconnected operation. With cvs I can do nearly nothing (related to version control, that is) offline. (Devs working on the plane, anyone?) With svn I can just check the status and the diff against the *current* pristine version. With git, for example, I can inspect the *whole* history up to
Re: About the OpenBSD repository
Hi, can we please stop this ? Some devs are aware of dvcs advantages, some use them locally for their own developments, some share things between some devs using dvcs public repos, some thinks that CVS has some weaknesses (which *might* be adressed in opencvs, once it is feature-compliant with gnucvs) some are against them and don't want to hear about them (for their own reasons), we've already discussed that at length on misc, there's no point in arguing more. Thx.
Re: About the OpenBSD repository
I used git twice. Once I lost hours worth of work and the second time it munged instead of merged the code. No thanks. If it works for you great, now stop evangelizing some retarded versioning system that will never, ever, ever, ever, ever be used in OpenBSD. On Tue, Jun 23, 2009 at 03:16:59PM +0200, Hannah Schroeter wrote: Hi! On Tue, Jun 23, 2009 at 07:39:41AM -0500, Marco Peereboom wrote: Manure alert! On Tue, Jun 23, 2009 at 02:16:39PM +0200, Hannah Schroeter wrote: On Mon, Jun 22, 2009 at 02:11:21PM -0500, Marco Peereboom wrote: What is wrong with CVS? And no I am not talking about the hypotheticals and some bugs that exist in the current code (that can also be easily worked around). - It's *slow* (once you've seen git's speed, both cvs and svn are snails against it; hg and bzr might perhaps compare with it, though). It isn't slow. I can check out a tree in a minute. Here is a nickel kid go buy yourself some real disks. Ok, just checked with git: Linux-2.6 tree. Update after about one month: I did by purpose separate the update into two parts: git fetch, then git merge instead of the usual git pull, so I can measure timing separately. git fetch origin (roughly equivalent to cvsync): about one minute, received a bit more than 17 MiB of data, roughly 8,5k changes (not files, but tree changes/commits) from the last update. git merge origin/master (roughly equivalent to cvs up with appropriate options, up-to-date-check/check for conflicts, reset the local branch to the remote branch and checkout files): 7738 files touched, 1m51 real time. That's with a normal local desktop style disk, not with a high end raid system or something like that. That is, a disk where it takes *several* minutes to cvs up, and where it takes *several* minutes to check for changes even after less time. (time git status, i.e. check for local changes: less than 10 seconds on the same tree). - How often you've seen people (devs with commit access) do development without committing it because it wasn't ready for prime time, then committing it in chunks that can't be grokked any more because they have accumulated for months or even over a year? You can't have off-site development branches in centralized version control systems. You *can* with distributed ones. You can merge them *and keep history* later somewhat easier than without having distributed vcs abilities. Oh I guess the cvsync tree I have on my laptop and all my development trees don't count. This is all uninteresting blabbing of someone who doesn't know how to use cvs. I have a cvsync tree too. But your local trees etc. aren't versioned the same way as they were with a dvcs. You can't commit to a cvsync tree the same way as you can commit locally with a dvcs. (Because your local commits would be overwritten on the next cvsync call.) You can, of course, have several local checkouts from the local cvsync tree with non-versioned, non-committed modifications. But if you have *one* strand of local development going on where one step depends on the next one, you can't version those steps in a structured *tool-supported* way with a centralized version control system. (You can do so without tool support if you copy out every version/commit to a separate directory tree, which takes more time and space than a local commit in a dvcs. That's about the same degree of organization as it was when one had foo.c.version1, foo.c.version2 in times when our company didn't use version control at all.) - Non-committers can keep track of their local modifications in a more structured ways (because they can too have local inofficial branches) with a distributed vcs. So submission of patches can be more structured. see previous. - Did I mention: most current dvcs are *fast*. And you can usually mirror the repo (just as cvsync does, just you don't need an addon tool for it). *yawn* - The history is still kept at a file level. While we see commit mails in a changeset form, if I want to look at what has been changed, I have to check per file (first cvs log, then cvs diff, or the equivalent thereof on the web). Even with svn I can do so with *one* svn log, then svn diff for the *whole* commit. With git I can do so with *one* git log -p for the whole commit (no further diff operation). Sure you found a nice feature but hardly killer or worth any downtime and relearning of some other retarded system that is full of unknown bugs. My experience is different. I deferred that learning curve for some time, too, when friends already were telling of their (in their experience, of course) good experiences with dvcs. Later I took some spare time for that. Now even some co-workers sometimes moan about some lacks of the company's centralized-only version control. I haven't really, yet, stumbled over annoying problems
Re: About the OpenBSD repository
On 23 Jun 2009, at 13:17, Hannah Schroeter wrote: Hi! On Mon, Jun 22, 2009 at 10:16:12PM +0100, Anil Madhavapeddy wrote: Pretty much every single new revision control system can import/ export from CVS, so use whatever you want... I tried git cvsimport on OpenBSD's tree and it failed, alas. cvs2svn doesn't grok some peculiarities of OpenBSD's tree either. Don't import the whole tree; I just import sub-trees as I need them. E.g., for lynx: http://github.com/avsm/openbsd-lynx-working/tree/master It's easy to go back and forward, or at least quicker than changing the entire workflow of a project for. -anil
Re: About the OpenBSD repository
Marco Peereboom wrote: I used git twice. Once I lost hours worth of work and the second time it munged instead of merged the code. No thanks. If it works for you great, now stop evangelizing some retarded versioning system that will never, ever, ever, ever, ever be used in OpenBSD. since it is *clear* that other vcs besides cvs will not be used, everyone should stop posting to this thread. this is an exercise in idiocy.
Re: About the OpenBSD repository
[...] To assume that it is not superiour in the particular application to which it is being put is also ridiculous. Having 1000 extra features you don't use and will never use is not an advantage. If one hasn't tried it out, it's difficult to assume one would never use features like disconnected operations (devs on planes), local/inofficial branches (devs working on new features that aren't ready for prime time yet; I'm committing this, disconnected from the build, so others can work on it wouldn't be completely necessary either, for example, if one could share experimental branches using a dvcs). But even for traditional operations... I'm for example hooked on the mere speed of git compared to svn or cvs even for a not so big tree like a private web project. And even for that I use the fact that both repositories are equals. At home, I commit to the local repository on the home box. Elsewhere I might remote-login to a leased server where another repository lies (and where also the http server is, using a 3rd copy which always is on the public branch, while the other repositories also have other branches). Or I might temporarily clone the repository from the leased server, work locally (perhaps doing more than one revision), then push the work (in one hunk!) back to the leased server and publish (i.e. update the public branch to the http server's directory). Especially over slow lines, definitely an advantage over having only one central cvs/svn repo on the leased server and only working copies on the other boxes. Local operations are *fast* (e.g. switching from one branch to another with git checkout, compared to cvs up -r... for switching the branch or svn switch or ...). Blah blah blah blah You just like listening to yourself talk. Shut up.
Re: About the OpenBSD repository
On Mon, 22 Jun 2009, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? To FAQ: 1. Why we use cvs? 2. Why we don't WANT to use svn, git, etc.? 3. What I should not question in an OpenBSD mailing list? 4. What am I doing here? -- Daniel Bolgheroni m...@dbolgheroni.eng.br FEI - Faculdade de Engenharia Industrial http://www.dbolgheroni.eng.br/mykey ASCII ribbon campaign ( ) against HTML e-mail X / \ mQGiBEjsKN8RBACIeANsMaUPV5vlbI0B1WGElqhLXdyR941fInJesLFUV+QlJ1Xi qsmmCa2GTiz1SQm4g0N7FxOQeW42x9Iv0kg5vjwkZ7uC1LJDZlVvoThpnk007WYK h19X+fbpQkK1kjWDd7TNiebDdvRcvVFJybSfGsqmrw/qufZ67HffLb9T2wCgx7ml LjrFFlT3+18v6wy0T169DVsD/RU8fOfPwEK4Gc/BkfCB/JjHax2TYitMn9oNylYw VdkuyFoaCEU2GmGP1/R1uT5U3TsKa0vIVBIiDTAOyZKhLgMejNyagKn4PuLcMyqo CCV7uOPCuMsEFmXNDQekLhGpWlSD3vLoqr/mO0T867qZjIuQ9An58VLcX6LSdGtG 6yV7A/0fJ4fC2+RJWLmHPKb8sgNpjByt7NjaumAGVqPPtGu9M6indImBB0HB+S3O 7vM0pf6rzfE69D9zc0ySJJ3tCo/r4TdMrx/tx6wbz/7pyfsIRbsCG+87VxqInnEP cg0zlN749NwBouPa2UTYMxXsJuv0OmX3W7EZ3vgL9lQ1BWzZn7QRRGFuaWVsIEJv bGdoZXJvbmmIYAQTEQIAIAUCSOwo3wIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheA AAoJEP423E9NZH/MPBMAmgNfL1njMlTBhhxiDdKsd6BLlcizAKCmVIP0jDarapBp j7FUQgJ3npAvS7kBDQRI7CjfEAQAl6exFKqLkBCjr8s5XoadLpvSFE5faif5l6q6 HcfKP2FFtUfSj46cvCLVYzip78KJjxGkksS36rrrKfgHH7z+2Oem+G5drtvMWmeA 14tFvJGWHKL1WR5P1fe593aaw8CHmiQxSkENyVN+Q8FvqUoZ5tPtGqVzlPmflU5K bcJphs8AAwUD/1CyyvbvMWNDPJLqZI1TiEkg3+2Kc67CFXhoS4DYCgObjnhA7GOO BB0PXHPMhtwqIhCQA0+u2YOstreW1UT+zY3ynQbc7bnHmCdRzEmCRLSqe44+nWkY QXD5tEOuMtAjJDQm7wQxRXA9EQouz4CLxz7uhEa5MJjoGdNkIqzDc/tCiEkEGBEC AAkFAkjsKN8CGwwACgkQ/jbcT01kf8yHNQCfV+eHlKqAwdPfnM9IxGiKotVXeEYA oKr5TGPxFG04Q3QnwX4+Acu78Svu =mJV8 -END PGP PUBLIC KEY BLOCK-
Re: About the OpenBSD repository
On Wed, Jun 24, 2009 at 3:14 PM, Daniel Bolgheronim...@dbolgheroni.eng.br wrote: 1. Why we use cvs? It works [enough]. 2. Why we don't WANT to use svn, git, etc.? See above. Also, why would we want to? (Don't answer that, you're wrong.) 3. What I should not question in an OpenBSD mailing list? The development process. It's a good bet that the people who have been developing OpenBSD for 10 years know more about how it's developed than you do.
Re: About the OpenBSD repository
On Tue, 23 Jun 2009, Ted Unangst wrote: On Wed, Jun 24, 2009 at 3:14 PM, Daniel Bolgheronim...@dbolgheroni.eng.br wrote: 3. What I should not question in an OpenBSD mailing list? The development process. It's a good bet that the people who have been developing OpenBSD for 10 years know more about how it's developed than you do. Don't take these as my questions. I read this mailing list time enough to know this. -- Daniel Bolgheroni m...@dbolgheroni.eng.br FEI - Faculdade de Engenharia Industrial http://www.dbolgheroni.eng.br/mykey ASCII ribbon campaign ( ) against HTML e-mail X / \ mQGiBEjsKN8RBACIeANsMaUPV5vlbI0B1WGElqhLXdyR941fInJesLFUV+QlJ1Xi qsmmCa2GTiz1SQm4g0N7FxOQeW42x9Iv0kg5vjwkZ7uC1LJDZlVvoThpnk007WYK h19X+fbpQkK1kjWDd7TNiebDdvRcvVFJybSfGsqmrw/qufZ67HffLb9T2wCgx7ml LjrFFlT3+18v6wy0T169DVsD/RU8fOfPwEK4Gc/BkfCB/JjHax2TYitMn9oNylYw VdkuyFoaCEU2GmGP1/R1uT5U3TsKa0vIVBIiDTAOyZKhLgMejNyagKn4PuLcMyqo CCV7uOPCuMsEFmXNDQekLhGpWlSD3vLoqr/mO0T867qZjIuQ9An58VLcX6LSdGtG 6yV7A/0fJ4fC2+RJWLmHPKb8sgNpjByt7NjaumAGVqPPtGu9M6indImBB0HB+S3O 7vM0pf6rzfE69D9zc0ySJJ3tCo/r4TdMrx/tx6wbz/7pyfsIRbsCG+87VxqInnEP cg0zlN749NwBouPa2UTYMxXsJuv0OmX3W7EZ3vgL9lQ1BWzZn7QRRGFuaWVsIEJv bGdoZXJvbmmIYAQTEQIAIAUCSOwo3wIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheA AAoJEP423E9NZH/MPBMAmgNfL1njMlTBhhxiDdKsd6BLlcizAKCmVIP0jDarapBp j7FUQgJ3npAvS7kBDQRI7CjfEAQAl6exFKqLkBCjr8s5XoadLpvSFE5faif5l6q6 HcfKP2FFtUfSj46cvCLVYzip78KJjxGkksS36rrrKfgHH7z+2Oem+G5drtvMWmeA 14tFvJGWHKL1WR5P1fe593aaw8CHmiQxSkENyVN+Q8FvqUoZ5tPtGqVzlPmflU5K bcJphs8AAwUD/1CyyvbvMWNDPJLqZI1TiEkg3+2Kc67CFXhoS4DYCgObjnhA7GOO BB0PXHPMhtwqIhCQA0+u2YOstreW1UT+zY3ynQbc7bnHmCdRzEmCRLSqe44+nWkY QXD5tEOuMtAjJDQm7wQxRXA9EQouz4CLxz7uhEa5MJjoGdNkIqzDc/tCiEkEGBEC AAkFAkjsKN8CGwwACgkQ/jbcT01kf8yHNQCfV+eHlKqAwdPfnM9IxGiKotVXeEYA oKr5TGPxFG04Q3QnwX4+Acu78Svu =mJV8 -END PGP PUBLIC KEY BLOCK-
About the OpenBSD repository
Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? Thanks in advanced. -- -- Fernando Quintero http://nonroot.blogspot.com/ *Just a nonroot User*
Re: About the OpenBSD repository
If it ain't broken don't fix it. What is wrong with CVS? And no I am not talking about the hypotheticals and some bugs that exist in the current code (that can also be easily worked around). I have used just about all versioning systems, including ones that have the price tag of islands in the pacific, and ultimately they all suck in their special ways. CVS works well-enough. On Mon, Jun 22, 2009 at 01:44:45PM -0500, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? Thanks in advanced. -- -- Fernando Quintero http://nonroot.blogspot.com/ *Just a nonroot User*
Re: About the OpenBSD repository
Pretty much every single new revision control system can import/export from CVS, so use whatever you want... -anil On 22 Jun 2009, at 19:44, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? Thanks in advanced. -- -- Fernando Quintero http://nonroot.blogspot.com/ *Just a nonroot User*
Re: About the OpenBSD repository
On 23/06/2009, at 6:44 AM, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? You seem to make the assumption that _everything_ else is better than CVS. This may be your opinion, but that's all it is. paulm
Re: About the OpenBSD repository
Paul M wrote: On 23/06/2009, at 6:44 AM, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? You seem to make the assumption that _everything_ else is better than CVS. This may be your opinion, but that's all it is. paulm Well, I suppose it is better than RCS or SCCS, and in some small ways, CVS even did things right that SVN gets wrong (namely, tags). But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :)
Re: About the OpenBSD repository
On Mon, 22 Jun 2009, Mike Swanson wrote: Paul M wrote: On 23/06/2009, at 6:44 AM, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? You seem to make the assumption that _everything_ else is better than CVS. This may be your opinion, but that's all it is. paulm Well, I suppose it is better than RCS or SCCS, and in some small ways, CVS even did things right that SVN gets wrong (namely, tags). But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :) http://www.openbsd.org/why-cvs.html Because none of the above mentioned will allow for 70+ developers to update ~1.2GB/~140,000 files of source code, allow anonymous checkouts, has an available web based interface and interfaces with ssh. Instead though non atomic commits, expensive branches and almost 20 years of work arounds are utilized. Eugenio.
Re: About the OpenBSD repository
On Mon, Jun 22, 2009 at 07:13:51PM -0700, Mike Swanson wrote: Paul M wrote: On 23/06/2009, at 6:44 AM, Fernando Quintero wrote: Hello list, I have a question: I was reading about version control systems and i found a lot of the distributed software with best performance, but really i don't know much about it. There are some technicals or philosophicals reasons why the OpenBSD repository does not change to something other than CVS? You seem to make the assumption that _everything_ else is better than CVS. This may be your opinion, but that's all it is. paulm Well, I suppose it is better than RCS or SCCS, and in some small ways, CVS even did things right that SVN gets wrong (namely, tags). But to imply that CVS is better than (or equal to) Mercurial or Git is a bit ridiculous :) Well the OpenBSD devs have only read completely the source of CVS, and developed OpenCVS, so (i think) that they don't want to use another thing that they don't fully understand, and isn't BSD/ISC licensed (like mercurial or git). well that's my guess. also: read the archives, this has been discuted sometimes. -- DISCLAIMER: http://goldmark.org/jeff/stupid-disclaimers/ This message will self-destruct in 3 seconds.
