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 22 Mar 2010 19:04 Albert wrote: >In article <q8Kdne9XgswQNzjWnZ2dnUVZ_jKdnZ2d(a)giganews.com>, >Michael Plante <michael.plante(a)n_o_s_p_a_m.gmail.com> 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. >> >> >> >> >>>> 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? > >I have done a single C# project, to get C# on my cv. (Designing organ >pipes.) > >I just used Tortoise (shell around cvs) and am able to recover any >version of the software, including all misconfigured Visual Studio >projects (because that was about the first time I used it, I made >a lot of mistakes.) Yes, and? That question was solely addressed to Les, to find out what he was getting at. I was *not* suggesting using either (but I also was *not* condemning Tortoise). I don't think anyone here has objected to using version control, in general. >You *must* be prepared to recover from errors in your project >setup. Only a version control system that is totally independant >of your IDE can do that. >The Unix philosophy of different tools still rules! For the most part, but that's not something I really want to get into. >And then something else. >I hear sometimes that people don't want to use a program that >hasn't been updated for a few years. That is sometimes annoying, yes. >I for me don't want to use a version control system unless the >last design error has been removed 15 years ago, and no bugs >have surfaced for the last 5 years. >Call me conservative, but I may give Visual Source Safe a >shot when it exists 15 years. (Oh, I hear it has been discontinued >already. ;-) ) Just because the name came up in an explanation doesn't mean anyone was suggesting using Sourcesafe. I suspect you misunderstood. >Version control must be the pinnacle of reliability. >Everything else must take a back seat. Yes. >(And of course the data format must be documented, Yes. >So maybe I will not bother to try Source >Safe after all.) Good idea. Michael
From: steveu on 22 Mar 2010 20:26 >Albert wrote: >>I for me don't want to use a version control system unless the >>last design error has been removed 15 years ago, and no bugs >>have surfaced for the last 5 years. >>Call me conservative, but I may give Visual Source Safe a >>shot when it exists 15 years. (Oh, I hear it has been discontinued >>already. ;-) ) > >Just because the name came up in an explanation doesn't mean anyone was >suggesting using Sourcesafe. I suspect you misunderstood. I think he makes an important point. I've never seen a purely commercial revision control system I'd work with, because they have a bad history of disappearing, leaving behind an inadequate migration path to any newer tools. For all its limitations, CVS has been something you cold rely on being there. Even now it is falling into disrepair, there are robust migration tools for moving to SVN, GIT and various other platforms. Version control seems an area where only community support has been able to ensure the longevity most of us are looking for. Steve
From: Randy Yates on 22 Mar 2010 21:01 Erik de Castro Lopo <erikd(a)mega-nerd.com> writes: > 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. That _is_ a nice feature. > SVN does allow renames, but implements it as a delete followed > by an add and looses all revision history across the rename. Nah. You can always go back to the directory state before the delete and pick up the revisions. > Bzr, Darcs, Git, Mercurial all handle renames and preserve > history across the rename operation. I'm lukewarm on this one - seems like it depends on what you want. > 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. Well, I wouldn't consider this a major issue. How many times do you want to merge multiple branches where files have been renamed? And if you do, cleanup shouldn't be that hard. You mentioned svn can't do merging of multiple branches. Did you mean one simultaneous merge? Otherwise I believe you could use the branch update/trunk reintegrate sequence they mention in the manual one branch at a time. svn seems clunky, but I haven't seen anything in 4 years of svn use that makes me want to run to one of the newer VCS's, as nice as they may be. -- Randy Yates % "Watching all the days go by... Digital Signal Labs % Who are you and who am I?" mailto://yates(a)ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELO
From: Erik de Castro Lopo on 22 Mar 2010 23:03 Randy Yates wrote: > Erik de Castro Lopo <erikd(a)mega-nerd.com> writes: > > > SVN does allow renames, but implements it as a delete followed > > by an add and looses all revision history across the rename. > > Nah. You can always go back to the directory state before > the delete and pick up the revisions. Still way more trouble than having a tool that just does the right thing automatically. > > Bzr, Darcs, Git, Mercurial all handle renames and preserve > > history across the rename operation. > > I'm lukewarm on this one - seems like it depends on what you > want. Above all else, I want to be able to see every commit message that occured for file X. Most tools allow something like: bzr log X For SVN, that command only works back to the rename. For all the better tools it works back until the file was added to the repo (regardless of whether it was renamed or not). > > 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. > > Well, I wouldn't consider this a major issue. How many times do you want > to merge multiple branches where files have been renamed? Its about convienience. Its about not having to think "if I do such and such is the revision control tool going to complain". > svn seems clunky, but I haven't seen anything in 4 years of svn use > that makes me want to run to one of the newer VCS's, as nice as they > may be. Not even commiting code while on the train? What about a weekend away coding and camping (no internet, no mobile phone) ? Yes, I have done this: http://www.mega-nerd.com/erikd/Blog/codecon06.html http://www.mega-nerd.com/erikd/Blog/codecon08.html In fact I've been to every one of these since the first one in 2004 and that around the time I started using GNU Arch, one of the early distributed VCSs. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
From: Petter Gustad on 23 Mar 2010 03:47
Erik de Castro Lopo <erikd(a)mega-nerd.com> writes: > 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. After I got my EEE901 a couple years ago I'm amazed about how much work I get done while waiting for the subway, shopping with my wife, waiting to pick up the kids at practice, etc. I use GIT and commits to keep track of what I do as the sessions are quite short, and then squash some of the commits and then push it on to my GIT repos at home. Petter -- ..sig removed by request. |