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: Jerry Avins on 18 Mar 2010 11:04 http://www.joelonsoftware.com/items/2010/03/17.html is about version control. If you use VC software, it might be worth reading. Jerry -- Discovery consists of seeing what everybody has seen, and thinking what nobody has thought. .. Albert Szent-Gyorgi �����������������������������������������������������������������������
From: steveu on 18 Mar 2010 11:47 >http://www.joelonsoftware.com/items/2010/03/17.html is about version >control. If you use VC software, it might be worth reading. 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. Steve
From: Michael Plante on 18 Mar 2010 12:50 Jerry wrote: >http://www.joelonsoftware.com/items/2010/03/17.html is about version >control. If you use VC software, it might be worth reading. He's got a point. I just started using git in January, and it's quite good for source code, from everything I can tell. One problem I've noticed is self-induced: several weeks after touching a branch, I start to forget why I made *it*, as opposed to about two dozen other branches. :-) I'm wondering if it makes sense to continue using svn or similar for binary files that cannot be merged (or at least not without great difficulty). At least then you even *can* lock it. I'm thinking about PCB layouts, excel sheets (bills of materials), etc., particularly proprietary files, but non-line-oriented files in general, to a lesser extent. The other concern I have (and there's probably an answer if I search, but I don't care enough yet) is how much stuff I can shove into a git repo before it becomes too slow. I recall watching the Torvalds talk at Google (IIRC), and he said giant things like KDE were a problem to put all in one place.
From: Steve Pope on 18 Mar 2010 14:48 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. I have used both, I find both usable, and in basic usage they behave nearly identically. What do you see as the key problem in the underlying model? Steve
From: Vladimir Vassilevsky on 18 Mar 2010 15:01
Steve Pope wrote: > 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. > > > I have used both, I find both usable, and in basic usage > they behave nearly identically. > > What do you see as the key problem in the underlying model? 1. They keep track of *files*, not *changes* to the files. 2. They have to keep everything in one dedicated place. If the large project is branched out, merging between the branches could be a royal PITA in this model. As in the article suggested by Jerry, I have to do the code with zillion of if() and #ifdef instead of branching. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |