Spolsky's last (it says here) opinion piece
in [DSP]
|
Prev: Hilbert Transformer Designed Using the Frequency-Response Masking Technique
Next: Question about Gaussian smoothing
From: Erik de Castro Lopo on 21 Mar 2010 05:14 Steve Pope wrote: > I want to learn about Git and its advantages, but blanket > statements about CVS's uselessness don't induce me to followup. First of all, I'd say you are ignoring that fact that while 10 years ago over 90% of Open Source projects used CVS, now its less than 5%. These projects abandoned CVS because CVS has problems and the new systems have features that people want. Secondly, you should note than many projects moved from CVS to SVN, only to later move to one of the more advanced ones. Again, features or rather SVN's lack of them prompted the move. So lets look specifically at the shortcomings of CVS and SVN. The main problem with CVS that none of the others have is that CVS has a per-file revision number. This means that if a set of changes are commited together, the files may end up with different revision numbers. SVN and all of the others get this right; each commit is atomic and has a unique revision number or identifier for all files at the time of the commit. CVS and SVN do not allow offline commits. Bzr, Darcs, Git and Mercurial all allow offline commits that can be pushed to a central location once the developer is back online. I used to do a lot of hacking on the train to and from work. It would not be uncommon for me to do three or four discrete commits per journey. CVS does not do renames. They can be emulated by deleting the file under the old name, and adding it again under the new name. However, you loose all revision history across the rename operation. SVN does allow renames, but implements it as a delete followed by an add and looses all revision history across the rename. Bzr, Darcs, Git, Mercurial all handle renames and preserve history across the rename operation. Now consider a more complex case where there are two branches A and B, a file X is renamed in branch A and modified in branch B. Now you try to merge from A to B or from B to A. I know at least Bzr and Git handle both of these cases correctly and I would be very surprised if any of them didn't. Above are just some of the advantages of these more advanced distributed revision control systems. Until you've used one, in anger, for an extended period of time, the features seem completely superflous. However, once you've used them, you can never imagine going back. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
From: Steve Pope on 21 Mar 2010 05:34 Erik de Castro Lopo <erikd(a)mega-nerd.com> wrote: >Steve Pope wrote: >> I want to learn about Git and its advantages, but blanket >> statements about CVS's uselessness don't induce me to followup. >First of all, I'd say you are ignoring that fact that while >10 years ago over 90% of Open Source projects used CVS, now >its less than 5%. These projects abandoned CVS because CVS >has problems and the new systems have features that people >want. Okay >Secondly, you should note than many projects moved from CVS >to SVN, only to later move to one of the more advanced ones. >Again, features or rather SVN's lack of them prompted the >move. >So lets look specifically at the shortcomings of CVS and >SVN. >The main problem with CVS that none of the others have is that >CVS has a per-file revision number. This means that if a set >of changes are commited together, the files may end up with >different revision numbers. SVN and all of the others get this >right; each commit is atomic and has a unique revision number >or identifier for all files at the time of the commit. Yes, I have noticed this about SVN as opposed to CVS. It is an improvement, in that one developer can say to another, "Use revision 7291 for this". In CVS you cant' really do this (although, your coping mechanisms... "use a version dated 7:30 p.m. on Wednesday"... are usually workable). >CVS and SVN do not allow offline commits. Bzr, Darcs, Git and >Mercurial all allow offline commits that can be pushed to a >central location once the developer is back online. Similar to BK? I do like that feature of BK. But if you want to do the same thing in CVS, you can. (e.g. clone, edit/commit to clone, diff to main, copy, check into main. Does that qualify as a PITA?) >I used to do a lot of hacking on the train to and from work. >It would not be uncommon for me to do three or four discrete >commits per journey. >CVS does not do renames. They can be emulated by deleting the >file under the old name, and adding it again under the new >name. However, you loose all revision history across the >rename operation. Nods. Of coures, renaming any file or object is a last-resort, usually stupid thing to do because it will confuse some poor developer, or some hapless build sript, somewhere. >SVN does allow renames, but implements it as a delete followed >by an add and looses all revision history across the rename. I have been using SVN recently and cannot find any advanted over CVS. My colleagues who like it like their IDE. >Bzr, Darcs, Git, Mercurial all handle renames and preserve >history across the rename operation. Okay >Now consider a more complex case where there are two branches >A and B, a file X is renamed in branch A and modified in branch B. >Now you try to merge from A to B or from B to A. I know at least >Bzr and Git handle both of these cases correctly and I would >be very surprised if any of them didn't. So they track renamings and rationalize this during a subsequent merge. Yes I ack that CVS cannot do that. >Above are just some of the advantages of these more advanced >distributed revision control systems. Until you've used one, >in anger, for an extended period of time, the features seem >completely superflous. However, once you've used them, you can >never imagine going back. > >Erik Steve
From: Erik de Castro Lopo on 21 Mar 2010 05:47 Steve Pope wrote: > Yes, I have noticed this about SVN as opposed to CVS. It is > an improvement, in that one developer can say to another, > "Use revision 7291 for this". In CVS you cant' really do this > (although, your coping mechanisms... "use a version dated > 7:30 p.m. on Wednesday"... are usually workable). That is not very workable on globally distributed teams. Is that 7:30pm Pacfic time or UTC? > Similar to BK? I do like that feature of BK. I never used Bitkeeper. > But if you > want to do the same thing in CVS, you can. (e.g. clone, > edit/commit to clone, diff to main, copy, check into main. Does > that qualify as a PITA?) AFAIAC yes. > Of coures, renaming any file or object is a last-resort, I find that happens quite often during the early stages of a project when I'm still getting a feel for the requirements. Using a system which allows and handles renames easily means I don't think twice about renames or moving files up and down in the directory structure if that will result in better software. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
From: steveu on 21 Mar 2010 06:09 >Steve Pope wrote: > >> Yes, I have noticed this about SVN as opposed to CVS. It is >> an improvement, in that one developer can say to another, >> "Use revision 7291 for this". In CVS you cant' really do this >> (although, your coping mechanisms... "use a version dated >> 7:30 p.m. on Wednesday"... are usually workable). > >That is not very workable on globally distributed teams. Is >that 7:30pm Pacfic time or UTC? The time zone issue is easy to handle by project management, but it doesn't handle the vagueness of only specifying a minute. There may be multiple commits within a minute. On large projects commits tend to come in bursts towards the end of the working day. >> Similar to BK? I do like that feature of BK. > >I never used Bitkeeper. Its similar. >> But if you >> want to do the same thing in CVS, you can. (e.g. clone, >> edit/commit to clone, diff to main, copy, check into main. Does >> that qualify as a PITA?) > >AFAIAC yes. Its not just a PITA. Its not equivalent. Cloning, running a separate version control system, and then merging the end result looses all the interim commits. Distributed version control systems capture all the steps. >> Of coures, renaming any file or object is a last-resort, > >I find that happens quite often during the early stages of a >project when I'm still getting a feel for the requirements. >Using a system which allows and handles renames easily means I >don't think twice about renames or moving files up and down >in the directory structure if that will result in better >software. I've never worked on anything with a long life where a lot of file organisation, variable and function names, and many other aspects of the material didn't start to look awfully wrong over time. As a strong believer in things saying what they mean, I find the way CVS makes everyone reluctant to restructure and rename for greater clarity a *massive* drawback. Steve
From: Les Cargill on 21 Mar 2010 07:36
Michael Plante wrote: > Les Cargill wrote: >> Michael Plante wrote: >>> Les Cargill wrote: >>>> Michael Plante wrote: >>>>> Les Cargill wrote: >>>>>> Michael Plante wrote: >>>>>>> You don't really even have option 2 with SVN, in my experience, >>> because >>>>>>> history rewriting isn't really feasible. Yeah, you can svnadmin >>>>> dump/load >>>>>>> and do stuff with the backups, but who does that routinely just to >>> clean >>>>> up >>>>>>> commits so they're presentable? No one? >>>>>> So save the output of an "svn diff" for each "svn commit." Coupled > with >>>>>> patch ( which has an "invert" option), it's completely symmetrical. >>>>> You're right, you could do that (w/o ever touching svnadmin), but > it's >>>>> still a whole lot more trouble to do that in svn. >>>> It's seconds per rev. >>> Only if it's automated, but that's beside the point. When you're >>> reordering 10-30 patches, perhaps the same set of patches several > times, >>> that's annoying. >>> >> I am referring to a process where one item - a defect report, or a >> feature request - maps to exactly one diff. This may be a rather large >> diff. > > > Yes, that's a bit different from what I was talking about. If you imagine > several "defect reports" or "feature requests" all being committed around > the same time, and then having to go sort out which goes with which and > reordering them so that one is finished before the next one is committed > (and each doesn't necessarily go one-to-one, but, rather, 1+ patches per > "item"), that'd be a little closer. > > Again, I'm not saying it's not doable, but it's more of a pain. But what > you're talking about doesn't sound terribly challenging either way. > > Well, I suspect that "not terribly challenging" is pretty much the point :) The key is the bijective map between diffs and however you manage work orders. > > >>> We may be talking about two different things. (I was kind of afraid > this >>> was the case when you mentioned "invert", which has little relevance to >>> what I'm talking about.) Do you reorder your own tree this way, or > just >>> submit patches to someone *else*? >>> >> No, I commit them, but I keep a string of diff files as provenance. > > > Yeah, if you're only committing them once, we're talking about two > different things. > > I suppose... I can't imagine any advantage to what you describe. >>> Everyone on the project I work on using git has their own local repo > AND >>> their own remote repo. No one has "write" access to anyone else's > repo, >>> but yes, there's a server so that people can collaborate across > continents. >>> Red herring, I think. >>> >> Someone mentioned specifically that Linus Torvald did not >> like the idea of a server. *Shrug*. > > > Really? > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > That's on a server. I think a subtle point was being made earlier that he > wanted a distributed system. Such a system can still use a server, but a > server is not *required*. The point is somewhat secondary...I haven't > tried "svk" (not to be confused with svn), but it's perhaps something to > look at. > > Ah. Fair enough. > > >>>> If you're assuming an IDE, that's different. I personally think IDE >>>> are a mistake (they're nothing but vendor lock in) , but that's just >>>> my opinion. >>> The only one I tried was a mistake. But I gave it up after a couple > hours. >>> I assume you mean "IDE integration" (like the MSSCCI, which is > painful), >>> and you're NOT referring to an Explorer shell extension (like > TortoiseSVN >>> and friends). >>> >>> >> Unfamiliar with it. > > > Well, I'm trying to figure out what you meant by IDE in that snippet, not > trying bring up new things. Which aren't you familiar with, Any of them. I've used Tornado quite a few times, but neither of MSCCI nor TortiseSVN. I would definitely include TI CodeComposer as a liability, but it seems widely accepted. > and are they > related to what you disliked? I rather disliked the GUI that came with Turbo 'C' in the '80s, and most integrated editor/build environments since. > I suspect you probably do know the former, > just not by its real name (I had to google it myself). MSSCCI is the > interface that sourcesafe uses, and that other version systems need to > emulate to work with a lot of Windows software (everything from programming > IDEs to board layout software, it's unfortunately become a de facto > standard). When I used SourceSafe, it was integrated with ObjecTime. > I tried an svn plugin (could've been any version system; my > beef is NOT with svn here) for Visual Studio, and that's the first (and > only) time I ever had MSVC hang. Not to mention the interface encourages > the "lock" mentality, instead of merging, so it's difficult to use svn (or > other systems) to their fullest ability inside most IDEs. Is that what you > were trying to say? > Yes. And they also frequently force detritus which is not source code on you that requires some dancing with respect to what gets committed into a repository. > > > Michael > -- Les Cargill |