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 21 Mar 2010 09:22 Steve Pope wrote: >Erik de Castro Lopo <erikd(a)mega-nerd.com> wrote: >>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. Git doesn't really track renames in the repo. They are inferred later. In other words, you don't explicitly tell it you are renaming a file (you can tell it, but it's a convenience and the info isn't saved). If a rename is detected, a similarity index is printed when you ask for it (100% being a pure rename, less being additional mods on top). Michael
From: Steve Pope on 21 Mar 2010 13:24 steveu <steveu(a)n_o_s_p_a_m.coppice.org> wrote: >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. Thanks, this is the sort of information I have been looking for. I do want to investigate Git when I have a chance. (The present main project I am on uses CVS, SVN, and Git, but the subset I am tasked with is not using Git.) >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. I can appreciate that. Thanks. Steve
From: Petter Gustad on 21 Mar 2010 15:56 spope33(a)speedymail.org (Steve Pope) writes: > If you're going to merge a branch, why branch off in the first > place? I can have dozens of branches active at a given time. It's also easy to simply delete the branch if you figure out that you went down the wrong track. Petter -- ..sig removed by request.
From: Randy Yates on 21 Mar 2010 18:48 robert bristow-johnson <rbj(a)audioimagination.com> writes: > [...] > i use PC programs like Dia, but that's worse than ironic: i can't use > a decent Mac program to do some basic graphics work so i end up using > a PC??! Apple has fulfilled its destiny (i was so disgusted in the > 90's with those intel ads on TV with guys in multicolored clean-room > suits are dancing around with the first Pentiums). i mean, it's like > voting for Obama and finding out he's Bush (this actually hasn't > happened yet so just image it). can you sympathize at all with the > disappointment? i just wonder if there will have to be another little > revolution in computing like the Mac was originally with it's "Windows- > emulating" user interface. There is: linux. Get with it, dude. > computers are s'posed to serve *people*, not the other way around. Prexactly. -- Randy Yates % "Midnight, on the water... Digital Signal Labs % I saw... the ocean's daughter." mailto://yates(a)ieee.org % 'Can't Get It Out Of My Head' http://www.digitalsignallabs.com % *El Dorado*, Electric Light Orchestra
From: Albert van der Horst on 22 Mar 2010 17:22
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.) So a good version control system can shield you from the problems of Microsoft rather than exacerbate them. 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! 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. 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. ;-) ) Version control must be the pinnacle of reliability. Everything else must take a back seat. (And of course the data format must be documented, such that if the worst comes to the worst, I can write a program to read it 20 years from now. So maybe I will not bother to try Source Safe after all.) >Michael Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst |