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: Michael Plante on 20 Mar 2010 23:26 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 could see how patches may not have the >transitive property - two patches might collide in a way to >produce a defect that reversing either would fix - but that's >not the general case. I can't easily generalize yet. I have run into quite a few conflicts, just as a matter of course, but I don't know if it's better or worse... >> That could potentially >> be automated, but, AFAIK, it hasn't been. It wouldn't be quite the same, >> but it's close enough (dump/load would allow you to remove revisions >> entirely, but that's not entirely necessary). The question, in a modified >> form, still stands: would anyone ever actually bother to do what you >> suggest *in svn*, or is it just too much of a pain? >> > >I do this. I attach a note to bug reports or feature requests with a diff. 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*? >I still don't see why cvs or svn aren't sufficient. Maybe in an >environment where a review committee must push all changes, but even >then, there's a non-painful way. In that case, I'd have them review the >diff, anyway. Yes, code review is good. (I hope that's not your point.) >I have used either CVS or svn for over half of the last 21 >years. I have not had any trouble with either. I didn't say it was troublesome, at least when that was all I was using. I just didn't think in terms where I knew what I was missing, so all was well in my mind. It's a specific case of only being familiar with something less capable, and "ignorance is bliss." >Indeed, so far >as maintenance goes, unless you do it "diff driven", it's very >difficult to keep track of where you are. I'd claim new >development is but a special case of maintenance. I'm not sure I follow. >Having to have a >server is no defect; you probably want it on conditioned power and >a UPS anyway. Might want RAID and other hardening as well. Agreed. I don't know how a discussion of a server came into this. 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. >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). >Obviously if your organization is embracing UML, it might >make sense. But CASE tools usually last less than five years in the >marketplace, then IBM buys them and they slowly fade away. Eh, the only UML I've done is on paper, so I can't answer that. >> One thing I'm not sure about is whether the patches generated that way >> would apply cleanly less often than if the history were there (I don't >> know). >> > >The "patch" tool is completely independent of svn. Exactly my point. Again, I don't know if it's a problem (though you're either helping my point or making no difference), but the very fact that "patch" is independent means it has no access to the history of the 2 (+) branches. Michael
From: Les Cargill on 21 Mar 2010 00:46 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. > >> I could see how patches may not have the >> transitive property - two patches might collide in a way to >> produce a defect that reversing either would fix - but that's >> not the general case. > > I can't easily generalize yet. I have run into quite a few conflicts, just > as a matter of course, but I don't know if it's better or worse... > > > >>> That could potentially >>> be automated, but, AFAIK, it hasn't been. It wouldn't be quite the > same, >>> but it's close enough (dump/load would allow you to remove revisions >>> entirely, but that's not entirely necessary). The question, in a > modified >>> form, still stands: would anyone ever actually bother to do what you >>> suggest *in svn*, or is it just too much of a pain? >>> >> I do this. I attach a note to bug reports or feature requests with a > diff. > > 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. > >> I still don't see why cvs or svn aren't sufficient. Maybe in an >> environment where a review committee must push all changes, but even >> then, there's a non-painful way. In that case, I'd have them review the >> diff, anyway. > > Yes, code review is good. (I hope that's not your point.) > > >> I have used either CVS or svn for over half of the last 21 >> years. I have not had any trouble with either. > > I didn't say it was troublesome, at least when that was all I was using. I > just didn't think in terms where I knew what I was missing, so all was well > in my mind. It's a specific case of only being familiar with something > less capable, and "ignorance is bliss." > That's always possible. Generally, any features other than what CVS or svn offer seem of very low utility to me. > >> Indeed, so far >> as maintenance goes, unless you do it "diff driven", it's very >> difficult to keep track of where you are. I'd claim new >> development is but a special case of maintenance. > > I'm not sure I follow. > > >> Having to have a >> server is no defect; you probably want it on conditioned power and >> a UPS anyway. Might want RAID and other hardening as well. > > Agreed. I don't know how a discussion of a server came into this. It was brought up elsethread. > 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*. > > >> 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. > >> Obviously if your organization is embracing UML, it might >> make sense. But CASE tools usually last less than five years in the >> marketplace, then IBM buys them and they slowly fade away. > > Eh, the only UML I've done is on paper, so I can't answer that. > > > >>> One thing I'm not sure about is whether the patches generated that way >>> would apply cleanly less often than if the history were there (I don't >>> know). >>> >> The "patch" tool is completely independent of svn. > > Exactly my point. Again, I don't know if it's a problem (though you're > either helping my point or making no difference), but the very fact that > "patch" is independent means it has no access to the history of the 2 (+) > branches. > > Michael > -- Les Cargill
From: Michael Plante on 21 Mar 2010 01:11 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. >> 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. > >> 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. >>> 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, and are they related to what you disliked? 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). 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? Michael
From: Steve Pope on 21 Mar 2010 03:47 robert bristow-johnson <rbj(a)audioimagination.com> wrote: >On Mar 18, 11:47 am, "steveu" <steveu(a)n_o_s_p_a_m.coppice.org> wrote: >> SVN is one of the saddest open source projects. So much effort when into >> reimplementing CVS without its problems, totally missing that its key >> problem is the underlying project model it implements. >> Mercurial and Git seem to be slowly taking over, but it takes people I >> while to get their heads around them. >so Steve, what is to be gained with a VC that requires getting one's >head around? I sense a repeat of when "vim" was introduced. The vim developers seemed convinced their product was orders of magnitude better than vi, but when you read what they had to say about it, it was clear they never actually learned how to use vi effectively, which was why they didn't like it. To this day, I dislike some vim features/behavior that I'm unable to turn off. I want to learn about Git and its advantages, but blanket statements about CVS's uselessness don't induce me to followup. Steve
From: steveu on 21 Mar 2010 04:37
>robert bristow-johnson <rbj(a)audioimagination.com> wrote: > >>On Mar 18, 11:47 am, "steveu" <steveu(a)n_o_s_p_a_m.coppice.org> wrote: > >>> SVN is one of the saddest open source projects. So much effort when into >>> reimplementing CVS without its problems, totally missing that its key >>> problem is the underlying project model it implements. > >>> Mercurial and Git seem to be slowly taking over, but it takes people I >>> while to get their heads around them. > >>so Steve, what is to be gained with a VC that requires getting one's >>head around? > >I sense a repeat of when "vim" was introduced. The vim developers >seemed convinced their product was orders of magnitude better than >vi, but when you read what they had to say about it, it was >clear they never actually learned how to use vi effectively, >which was why they didn't like it. Its distributed control is nothing like vim. vim is to vi as svn is to cvs. They were both going to cure all the ills of their predecessor, when that was an impossibility. In the case of vim you just ended up with vi, which you either love or hate. With svn you just end up with cvs, which only a mother could love. >To this day, I dislike some vim features/behavior that I'm unable to >turn off. > >I want to learn about Git and its advantages, but blanket >statements about CVS's uselessness don't induce me to followup. I find it hard to believe anyone could seriously use CVS for any length of time, and not learn to hate it. Its a straight jacket that paralyses projects. Nobody wants to restructure anything, as it would anger the CVS gods. Nobody wants to rename anything to something more meaningful, as it would anger the CVS gods. Nobody wants to go off on their own with grand experiments, as it would anger the CVS gods. Hg and GIT aren't perfect, but surely any serious CVS user yearns for something a little less of a PITA? Steve |