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 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. I do. Have used it for long enough. Of course, with *addon* utilities like cvsync you can substitute for *some* things (local history inspection). Non-OpenBSD projects often don't offer cvsync. There's some other tool to mirror cvs history from standard cvs servers, but that's *slow*. With dvcs, mirroring history is a standard use case, and it's fast. (See the one minute from above with significant changes, with cvsync I get a bit less than one minute when re-running with nearly no more changes, with a scanfile, of course. And sometimes cvsync has hickups which I have to fix by switching around cvsync servers or throwing away the scanfile. BTDT, just recently.) But even with a local cvsync mirror, you can't - in a way supported by the tools - create new history (commits!) to be automatically synced (committed/pushed) upstream when you want to later. >> - 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. You probably didn't try. Of course, I don't use git stash every day. Usually I work on one thing until I can commit, so I don't need that. And then, I usually don't need selective committing either. But sometimes I notice I've gone on to the next topic while doing the first. *Then* it's nice to be able to select out the first topic in order to commit that separately (creating more readable history for other project members) with less manual work. Not often, but sometimes *really* 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. How often have I seen miscommits to be reverted immediately thereafter on source-chan...@? But also at work? People sometimes make mistakes. Editing local history makes it easier to correct them in a less intrusive fashion. It also makes it easier for me to create a more readable history after having done some topic work in an explorative fashion. Do this, notice some style stuff and correct that, do that, notice some more style stuff, etc. In the end, I make the history more readable by moving the style commits to the front (or to the end) and squashing them together, creating a history that has style commits separate from the functional changes, making the latter more readable for those who touch the code after me. >> - 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). >Boooooooring In the contrary. A little, but practical nicety. In my experience. If you want, YMMV, of course. >> >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... As said, I'm not the big fan of svn, either. But tree changesets are more readable for those who touch the code after you. Nearly everything except cvs or rcs does them nowadays. So your sentence is a strawman argument. There're more sane vcs than svn who do tree changesets too, like git. No "git cleanup" anywhere. >> 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. I.e. "make bigger commits than you'd actually like"? I subscribe to "commit small bits in order to create a more readable history". That's easier if the tools don't get in your way (i.e. commits are *fast*). Once you have tools that make history more readable (tree changesets, fast access to them), I think people will value reading the history and deducing "why are things the way they are" more. And thus also *writing* such a history. >These are the things people >point at all the time but I never see them as an issue IN THE REAL >WORLD. >> 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. >Good for you! Yes. YMMV. >> Kind regards, >Thanks for your opinion, I now like git as much as I did before wasting >my time answering this. I didn't force you to "waste" your time. If you chose to, it's your responsibility. Kind regards, Hannah.
