Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Toward Saner Version Control

By skyknight in Technology
Tue Oct 25, 2005 at 10:54:34 AM EST
Tags: Software (all tags)

Software engineering is not just a technical domain, but also an intensely social one. Once a project team grows beyond a single developer, the need arises to coordinate the parallel efforts of multiple contributors. To this end source code management tools exist.

Anyone who has worked on a software project with a team of people knows how difficult the coordination of efforts can be. Students of Fred Brooks' The Mythical Man Month, or people who understand it implicitly by virtue of their experiences in the work place, are well aware of this. Intelligence, quite simply, does not scale. The number of communication channels for a team grows with the square of the number of participants, and presumably the efficiency of such a team shrinks with a corresponding inverse relationship. To keep things from grinding to a halt, good tools must be at one's behest.

Among these tools, a good source code management tool must reside on a developer's belt. There are many options from which to choose, some better than others. In the open source and Unix community, CVS has long been a favorite. There also exist myriad commercial alternatives, such as ClearCase, Razor and Perforce. More recently, the open source community has added Subversion to its arsenal, a tool superior to CVS and one that has breathed new life into the non-commercial offerings.

CVS has long been maligned by proponents of commercial alternatives, but Subversion largely undermines any claims that proponents of such tools can make. For a full list of the improvements that Subversion makes over CVS, see the documentation, but the main ones follow...

For one thing, Subversion provides atomic commits. This is huge. When you commit code from your sandbox back to the repository, there exists a race condition with CVS that may cause you to fumble. When doing a commit, even a batch commit, you are actually just committing one file at a time. Furthermore, the commit operation may fail should it be the case that a newer version of the file has been committed since you last updated. If you try to commit a batch of files in CVS, it may be the case that one or more of the file commits may fail, leaving the repository in a broken state. This is bad, very bad. Subversion, on the other hand, operates not on a per-file basis for commits, but rather on the basis of change sets. You can commit a group of files together, and either they all commit or none of them commit. This does wonders to forfend breaking the build.

On a related note, revision numbers in Subversion are not done on a file by file basis. Rather, the whole repository has a revision number that increments with the commission of each change set. This has the advantage of lumping changes together into logical units. For a given revision number you don't really care that file Foo changed. What you want to know know is what feature was implemented for a given revision, and what modifications were made in the course of doing so. Subversion makes this a reality. From revision 442 to 443, you can see the list of files that changed, and the corresponding comment "fixed bug #256". To do this in CVS you will have to resort to ad-hoc measures, perhaps writing tools of your own.

Another big win with Subversion is that file renaming is a first class operation and directories are first class objects. In CVS, moving a file was a horribly clumsy operation. You had to copy the file to its new location, issue a delete command for the old location, and issue an add command for the new location. In the process of doing so you would lose the history of the file. If you did not wish to lose the file's history, you were literally forced to go into the repository and hand move the corresponding file at your own risk. That sucked, and with Subversion is entirely obviated. Now you just issue a "svn mv" command and life is good. Given how central this operation is to refactoring code, I wonder how I ever lived without it as a CVS user.

Another big gripe about CVS is the tedium of branching with it. In Subversion, branching is trivially easy. Whereas in CVS the general opinion seems to be that branching is akin to being bitten by rabid coyotes, in Subversion it basically consists of a directory copy operation. You issue a "svn copy" command, which is actually a light weight copy-on-write method, creating a new node in a directory tree that comprises the branch. An "svn merge" command specifying that branch will merge things to wherever you desire with minimal hassle.

All in all, Subversion is a fantastic tool, and one that I believe to represent the future of version control. However, this doesn't stop the snooty and recalcitrant proponents of commercial tools from claiming that Subversion is an inferior tool, and that everyone would be better off if only they would adopt a "real" tool. This claim, as far as I am concerned, is nonsense.

In dealing with said Philistines, it would seem that the most common complaint centers on Subversion's lack of deference to strict file locking. This is unfortunate, as said mechanism is in fact a crutch for a crippled process. If coordination of developers in your group depends on knowing who is editing what file, then, quite frankly, you are doing something very wrong.

In developing software, the fundamental unit of work is a feature, or perhaps a bug fix. The fact that you are operating on a directory tree of files is accidental. It is an artifact, something that is not an intrinsic facet of software development. Along these lines I would argue that file locking operations represent a faux feature. They provide a false sense of security that lulls developers into a state of complacency, a state of mind that assumes that everything is A-OK just as long as people aren't working on the same files.

Nothing could be further from the truth. If someone is working on file A, and a co-worker is working on file B, and file A includes file B, depending on the API that it exports, then the benefits of file locking to you are precisely NOTHING. The functionality provided by file B could change out from under the developer working on file A, and unless the developer working on file A is communicating with the developer working on file B, then he is hosed. That's all there is to it.

Quite simply, there is no substitution for good communication between developers. Furthermore, there is no tool in existence that truly facilitates it. You can lead a horse to water, but you can't make it drink. If your developers refuse to talk with one another, then there is no piece of software that can save you. Software development is a very social process, and if developers are not talking to one another then all is lost. File locking will not keep people from stepping on one another's toes. It will merely provide the illusion of concurrency management, and that illusion can oft prove disastrous.

Of course, it would seem that the various and sundry commercial tools are in the habit of providing such features. This begs the question, why? The answer, presumably, is simple. Lots of people are hot for the aforementioned security blanket, and commercial enterprises are typically more interested with making money than in improving the state of software engineering. As such, they are naturally inclined to give people what they want, even if what they want is stupid and short-sighted.

Software engineers don't need snazzy tools. They need solid tools, ones that implement a few core features in a robust fashion and that refrain from providing nonsensical features that appeal to PHBs and the talentless hacks who are self-styled "software engineers". As such, there exists a conflict between those who would sell said tools and those who would use them. Having smart developers who communicate effectively and write good suites of automated unit tests will buy you much more than any piece of software that comes in a shiny box.

This brings me to my last point... I have noticed a distinction between the various people that one encounters in the work place, a distinction made by Pirsig in Zen and the Art of Motorcycle Maintenance. Apart from the truly useless wards of the state, there are two kinds of people: those who are educated, and those who are trained.

Educated individuals tend to be generalists. They might be especially good in a few specific things, but that is not their main selling point. By far and away, their main virtue is adaptability. They have absorbed a large body of knowledge and generalized it into a framework that allows them to reason about and solve novel problems. They do not tend to get into ruts. They do not tend to bump up against walls and get stuck. No matter what the environment is into which they are thrust, they can adapt and prevail.

Trained individuals, when in their domain, are indistinguishable from educated folk, or perhaps even superior. They have absorbed some particular body of knowledge and are now purveyors of it in the same way that followers of a religion are purveyors of their faith. Pointed in the right direction they are very capable people. Put them up against a novel situation, however, and they are damn near useless. They will spout ideological nonsense that aligns with their programming, and there is quite simply nothing that you can do to convince them that there exists a better way. If they learned system A, and part of their indoctrination is that system A is the best system ever, then there is nothing in this world that you can do to convince them that system B is better. You may just as well try to make a Satanist of a fundamentalist Christian.

It is this latter variety of people against whom I have vainly butted my head trying to convince them of the insanity of relying on such silly features as strict file locking. It does not matter how destructive a reliance on such a strategy may be. If they cut their teeth on a broken process, and were trained instead of educated, then there is nothing that can be done to break them of this habit. You cannot reason with such people and are wasting your time in doing so.

Realistically speaking, it's probably going to be twenty to fifty years before we have a software development process that doesn't totally suck. Until then, your best bet is probably to use Subversion, write unit tests competently, and regularly chew the fat with your fellow developers. Also, for the love of God, use an editor that doesn't suck. If you're not using Emacs, then I hope that you're using vi, and if you're not using one of the two, then please kill yourself.

That is all.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Also by skyknight

Display: Sort:
Toward Saner Version Control | 263 comments (160 topical, 103 editorial, 0 hidden)
An idea for another article (none / 0) (#7)
by shm on Sun Oct 23, 2005 at 01:00:34 AM EST

I liked the comparision of the the educated versus the trained. I think that that's a key problem in the software business in particular, and the technology business in general.

There may be another article lurking in those two paragraphs.

Indeed, that occurred to me as well... (none / 0) (#25)
by skyknight on Sun Oct 23, 2005 at 09:12:14 AM EST

I will put it on the back burner of my brain, see what kind of interesting dialog comes out of this piece, and perhaps write a piece with that as the focus in the near future.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Christians and Satanists... (none / 1) (#9)
by Alien zombie on Sun Oct 23, 2005 at 02:25:45 AM EST

are flip sides of the same coin, so converting one to the other is a trivial operation.

Concerning education vs. the training, I don't believe the latter is an obstacle to adaptation --in fact many of the so-called educated treat their college experience as glorified vocational training and never really master critical thinking skills.

Associating "change sets" with their intended feature enhancements and/or bug fixes seems an obvious incremental improvement, but mitigates only a small subset of possible conflicts, since change sets may be mutually incompatible.

I'm not familiar with any of the tools you mentioned (except vi) since I haven't done any serious coding in over a decade.

Hm... I'm not sure that I can agree with that... (none / 1) (#17)
by skyknight on Sun Oct 23, 2005 at 08:12:45 AM EST

I think that the issue with religionists is that they are accepting something on faith. By the very definition of faith they aren't rigorously testing their hypotheses, namely because they tend to be of the untestable flavor. You have a similar mentality with people who are trained as opposed to educated. They were handed down fiats from upon high and have accepted them as Truth. Education, however, at least at a good university, tends to be relatively hands-off with respect to guiding one down a path. A good school won't tell a student what to study, but rather just provide lots of interesting opportunities to chew on meaty problems. Want to take a course on AI? Go for it. Interested in operating systems? Take a class on it. This is fundamentally different than having your eyes taped open and being forced to memorize the API for some tool or library. The former makes you an adaptable problem solver, and the latter makes you a robot.

Of course, to a large extent, education is what you make of it. You get out of school what you put into it. The truly capable people are the ones who didn't really need to go to college, but went anyway and got as much out of it as they could. There are brilliant people who come out of schools of which you have never heard, and there are countless worthless idiots who come out of schools with good name brand recognition for the simple fact that they had obscenely rich parents and didn't apply for financial aid. Yes, there are indeed plenty of worthless pukes who come out of university educations. Also, anyone who frequently talks of the pieces of paper hanging on his or her wall has a serious inferiority complex, and probably good reason for having it. Sitting in traffic, I am constantly amused by the masses of people who have plastered stickers on their cars pronouncing the university that they attended. I find myself thinking, "hm, that's nice, I attended schools far more elite than yours and you don't see my pasting gaudy stickers on my car, poseur".

As you note, while having atomic change sets is a big win, it does not solve all of the problems. It is still entirely possible to break the build. Atomic change set commits only protect you from the race condition involving new versions of files on which you were working having been committed to the repository since you last synchronized with the repository. This is why it is absolutely imperative that your code base have associated with it a good suite of automated unit tests. You should be running this test suite all the time, and in particular you should run it immediately before committing your code to the repository, but after you have synchronized with the repository. At the end of the day, you need both atomically committed change sets and robust unit tests. Having only the former buys you a hell of a lot, but you still need the latter if you're going to be serious about software development. Also, just as it is not possible for there to exist a tool that forces developers to communicate with one another when they refuse to do so, there is no tool that can force people to write good tests. Quite simply, there is no substitute for intelligent and engaging people, at least not until the dream of strong AI is realized.

As for the tools, I have used CVS for roughly the last five years, and I just started using Subversion this year. I hesitated for a while because I don't think Subversion was stable until just recently. It's a great piece of software now, though. As for the other tools I mention, I haven't actually used them, but in the work place I'm constantly dealing with people who are proselytizing about them. The usual "benefits" that they cite are precisely the ones that I opine as being crutches for fundamentally broken processes. Also, these people nearly always fall into the "trained" category. They probably went to some developer training off-site event, were subjected to the propaganda of a large corporation's marketing arm, and are forever more brain damaged in particularly annoying ways.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Take a class? (none / 0) (#36)
by Alien zombie on Sun Oct 23, 2005 at 12:17:59 PM EST

That attitude is so undergraduate.

Education is about the individual, not the school.

Automated tests are of great value, but one must always be aware of their limitations.

Strong AI is based on the assumption of substrate independence, which is a close cousin of the soul superstition. Semiconductor circuits will never be sentient, no matter what software they may run.

[ Parent ]

I think that comments I have made here... (none / 0) (#43)
by skyknight on Sun Oct 23, 2005 at 02:20:44 PM EST

would seem to indicate that I don't place any undue credence in the classroom. In fact, in many ways I am scornful of the present state of universities, viewing them as acting increasingly as paper mills instead of institutes of higher education. I actually do my best learning outside the classroom acting in an entirely independent fashion, either reading a good book or hacking on a piece of code.

Automated tests do indeed have their limitations. Tests cannot prove the absence of errors in code. They show only one thing: that the tests pass. However, nothing in life is truly certain in any meaningful way. We must forever deal with imperfect information, operating with probability distributions, using statistics as our guide. To this end, I think automated tests serve us pretty well. They won't catch everything, but everything they do catch frees up time for humans to deal with more interesting and difficult problems.

I am curious why you think that semi-conductor material could never be conscious. To me, this is a very odd statement, though quite common. What should be so special about our biological brains? Sure, it might be the case that the particular way in which we are wired is a requisite for consciousness as we know, but I see no reason to believe that that must be the case.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Best Learning Outside The Classroom (none / 0) (#172)
by rebelcan on Tue Oct 25, 2005 at 12:21:29 PM EST

I agree with you on the "do my best learning outside of the classroom" part.  I finished my first year of college/university last year, and I was well and truly suprised by how little most people in my classes knew. I actually spent most of my classes helping other people because I already knew most of what was being taught. My first year introduction to programming class was mostly "catch up on webcomics" time.

Granted, many of them had probably never really given much thought to why they were in a programming course. But there were some people that were really just their for the fancy piece of paper. And that kind of scared me. They would ask me to help ( or do ) their homework for them, but then complain that the tests were too hard.

Hmmm. Thinking about it now, those are propably the kind of people that have programming in the current state it's in. People who don't care about programming and are just in it for the money should get a different job. Don't code because it's an easy ( ok, easier ) way to make money, code because you enjoy it, damnit!

God is dead -- Nietzsche
Nietzsche is dead -- God
but Zombie Nietzsche lives! -- Zombie Nietzsche
[ Parent ]

Really? (none / 1) (#54)
by trhurler on Sun Oct 23, 2005 at 06:25:28 PM EST

So if semiconductor circuits can never be sentient, why can agglomerations of carbon, hydrogen, and oxygen?

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
There's no point arguing with him (none / 1) (#86)
by QuantumG on Mon Oct 24, 2005 at 01:42:28 AM EST

if you can't agree on substrate independance then there's no hope he'll ever think strong AI is reasonable. It doesn't really matter why he doesn't believe in substrate independance.. it could be as simple as "god doesn't love silicon" or it could be some long rambling argument about complexity, but in either case, you're not going to change his mind.

Gun fire is the sound of freedom.
[ Parent ]
Oh, (none / 1) (#89)
by trhurler on Mon Oct 24, 2005 at 02:51:44 AM EST

I can think up reasons why substrate independence might fail. I just don't think HE can, and I certainly don't think he can demonstrate the truth of any of them(I doubt it is possible with present technology, actually.)

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
If I were running the reality simulation... (none / 0) (#135)
by Alien zombie on Mon Oct 24, 2005 at 05:02:31 PM EST

your account would be deleted immediately.

[ Parent ]

Hmm (none / 0) (#142)
by trhurler on Mon Oct 24, 2005 at 09:49:19 PM EST

Maybe that's part of the reason why you're still "running" a ten speed and working for the local grocery.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
You exaggerate my ambition (none / 0) (#202)
by Alien zombie on Wed Oct 26, 2005 at 03:05:44 PM EST

[ Parent ]
Abundant empirical evidence... (none / 0) (#134)
by Alien zombie on Mon Oct 24, 2005 at 05:00:07 PM EST

supports my position. Despite massive increases in computational power over the last few decades, there is not one iota of evidence that computers are any closer to sentience now than they were in the sixties. Maybe you believe in some mystical threshold that is still many orders of magnitude away, but I see no reason to do so, especially since there is now theoretical support for my position:

Physical Review E
(Statistical, Nonlinear, and Soft Matter Physics)
Print Issue of November 2001
Phys. Rev. E 64, 051920 (2001) (8 pages)
(Received 5 April 2001; published 30 October 2001)

Intelligent systems in the context of surrounding environment

Joseph Wakeling and Per Bak
Department of Mathematics, Imperial College, 180
Queens Gate, London, SW7 2BZ, United Kingdom

Excerpt from abstract:

"In the context of these results, we discuss the general nature of natural and artificial intelligence systems, and suggest intelligence only exists in the context of the surrounding environment (embodiment)."

[ Parent ]

Look pal, (none / 0) (#145)
by trhurler on Mon Oct 24, 2005 at 09:53:26 PM EST

The "quantum" part of "quantum mechanics" means that the universe can be simulated(or at least a portion of it can be,) among other things. Are you going to claim that a simulation would not give rise to intelligence due to some mythical soul nonsense or what?:)

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Quanta are distinct bundles (none / 0) (#204)
by Alien zombie on Wed Oct 26, 2005 at 03:28:55 PM EST

of energy or matter. That is what distinguishes quantum mechanics from continuum mechanics. Either model may be simulated by computation, but simulations have no sense of self.

[ Parent ]
You're missing the point (none / 0) (#207)
by trhurler on Wed Oct 26, 2005 at 07:41:45 PM EST

A quantum universe can be simulated PERFECTLY.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
And a classical universe couldn't? (none / 0) (#218)
by Alien zombie on Thu Oct 27, 2005 at 06:24:58 AM EST

Quantum mechanics isn't the issue here anyway. You seem to believe that a simulation can somehow magically become sentient and that's silly. What you're doing is anthropomorphizing digital circuitry. You can simulate a hurricane, but that won't blow away the computer, because the cyber-storm isn't real.

[ Parent ]
Hmm (none / 0) (#223)
by trhurler on Thu Oct 27, 2005 at 08:02:13 PM EST

You seem to think that a blob of hydrocarbons can somehow magically become sentient and that's silly. What you're doing is anthropomorphizing chemicals. You can simulate a blob of hydrocarbons, but that won't make it smell bad, because the cyber-blob isn't real.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
The hydrocarb simulation won't smell (none / 0) (#225)
by Alien zombie on Thu Oct 27, 2005 at 08:59:29 PM EST

but brew up the blob and that will raise a stench.

[ Parent ]
You miss the point (none / 0) (#232)
by trhurler on Fri Oct 28, 2005 at 08:04:42 PM EST

To a simulated person, the simulated hydrocarbon brew WILL smell.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
I think current hardware supports setience (none / 0) (#175)
by GotoHospital on Tue Oct 25, 2005 at 01:08:59 PM EST

You have to respect that the hardware/software in our brains spent billions of years being developed. And there is a lot of complexity in the brain that is described in detail by genetics (nature not nurture).
nested¢ evolution is still interesting. talk.origins faq.
[ Parent ]
Awareness is more analog (none / 0) (#203)
by Alien zombie on Wed Oct 26, 2005 at 03:16:18 PM EST

than digital. I respect the evolved complexity we represent, which is absurdly oversimplified by strong AI enthusiasts.

[ Parent ]
Did you even read that paper? (none / 0) (#227)
by schrotie on Fri Oct 28, 2005 at 05:23:18 AM EST

It's not about about "sentience" (though that notion is mentioned), but about intelligence. And the notion of intelligence is applied to the simulated agents, which are presumably simulated on silicone.

BTW, considering embodiment as a prerequisite of intelligence and sentience is no news. Rodney Brooks postulated that two decades ago. He's the one you should quote. But then he has spend the last two decades trying to implement cognitive embodied systems that use silicone as their brain matter. If you want to quote somebody to support your views, you are looking into the wrong direction. All these AI people would not be in that research if they shared your view. Actually I don't know quotes to support your view, but you might find some from biologists, medics or psychologists. Probably some philosophers and certainly theologists.

Finally, if you guys are discussion about sentience, you might want to try defining that term or at least quote somebody (like Metzinger) who has spend some of his wetware's processing time on that matter. I don't see much more than babbling in this thread.

[ Parent ]

Intelligence isn't processing power or magic (none / 0) (#253)
by cburke on Thu Nov 03, 2005 at 09:17:35 AM EST

The only thing your "empirical evidence" shows is that the ability to perform four billion additions per second doesn't somehow automatically produce intelligence.  There is no "threshold" where making a computer faster would also make it smart, and no reason to expect there to be.  This is so obvious that I don't see why evidence is neeeded, yet it also does nothing to argue against the possibility of strong AI.  It just means Moore's Law isn't how you get there.  Big deal.

The real problem is that computers are made and programmed by humans, and humans don't understand intelligence.  Therefore it is completely unsurprising that "massive increases in computational power" haven't magically resulted in AI, because we don't know how to make one no matter how fast a computer we use.  It may be that a 386 has all the computational power needed.  You may think that biological computers are special, but even if we were using organic neurons instead of silicon transistors to form our computers, it is highly unlikely that we could make an intelligent brain because we don't understand what makes intelligence.

To paraphrase Arthur C Clark:  Any sufficiently complex process is indistinguishable from magic if you don't know how it works.

Lightning was magic to our ancestors, unexplainable and unreproduceable.  Now we understand it, it isn't magic at all, and we can even recreate it to a limited extent.

Right now, intelligence is magic to us.  Surprise: we aren't magicians, we can't create intelligence.

Believing that this makes creating intelligence impossible, that our naturally evolved brains contain something that no constructed system ever could, is to believe that intelligence truly is magic.

Do you believe that which you don't understand must be magic?  

By the way, why do you feel the abstract excerpt you quoted precludes strong AI?  Any useful AI is going to have some form of input, aka "senses".  Your senses are your brain's only connection to the environment, so too would a computer AI's senses.

[ Parent ]

You forgot a few other elements (none / 0) (#132)
by Alien zombie on Mon Oct 24, 2005 at 04:40:04 PM EST

Simply stated, I believe that consciousness is a complex chemical phenomenon, this being easily demonstrated by imbibing a few beers, or partaking of whatever other mind-altering substance(s) you fancy.

[ Parent ]
Hmm (none / 0) (#141)
by trhurler on Mon Oct 24, 2005 at 09:47:46 PM EST

So you don't think it is possible to simulate chemical interactions? I find that to be an amusing conceit.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Simulations have no sense of self (none / 0) (#201)
by Alien zombie on Wed Oct 26, 2005 at 03:01:47 PM EST

And you're obviously an AI troll bot.

[ Parent ]
How would you know they have no sense of self?$ (none / 0) (#206)
by trhurler on Wed Oct 26, 2005 at 07:41:08 PM EST

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Because he simulated all of them, duh. (none / 0) (#211)
by skyknight on Wed Oct 26, 2005 at 09:47:26 PM EST

Why must you be so thick?

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Why didn't I think of that?$ (none / 0) (#216)
by trhurler on Thu Oct 27, 2005 at 01:14:31 AM EST

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Now that's recursive (none / 0) (#219)
by Alien zombie on Thu Oct 27, 2005 at 07:58:05 AM EST

simulating the simulations, leading to an infinite regress.

[ Parent ]
Do androids dream of electric sheep? (none / 0) (#220)
by Alien zombie on Thu Oct 27, 2005 at 08:01:26 AM EST

[ Parent ]
Maybe (none / 0) (#224)
by trhurler on Thu Oct 27, 2005 at 08:04:04 PM EST

How would we know?

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
And could we believe what they say? (none / 0) (#226)
by Alien zombie on Thu Oct 27, 2005 at 09:20:20 PM EST

Not sure if you caught my reference to the Philip K. Dick classic which was the inspiration for Bladerunner.

[ Parent ]
Do you believe (none / 0) (#233)
by trhurler on Fri Oct 28, 2005 at 08:06:28 PM EST

that other people around you are actually sentient?

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
I'm a big fan of solipsism, personally. (none / 0) (#234)
by skyknight on Fri Oct 28, 2005 at 08:30:45 PM EST

Especially after this week, it's hard to believe that anybody else is sentient.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Solitudinarianism is good enough for me (none / 0) (#238)
by Alien zombie on Sat Oct 29, 2005 at 08:55:57 AM EST

And there's no weekly flip-flopping allowed for solipsists.

[ Parent ]
You, sir, are mildly amusing simulation. $ (none / 0) (#239)
by skyknight on Sat Oct 29, 2005 at 10:02:15 AM EST

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Well, I guess you're on your own there. [nt] (none / 0) (#256)
by mettaur on Fri Nov 04, 2005 at 02:24:35 PM EST

[Applying business theory to trolling]
[ Parent ]
Not until they pass my Turing test (none / 0) (#237)
by Alien zombie on Sat Oct 29, 2005 at 08:47:04 AM EST

[ Parent ]
Is beer a tool? (3.00 / 5) (#12)
by bodza on Sun Oct 23, 2005 at 05:24:22 AM EST

I've always found it remarkably useful in facilitating communication between programmers.
"Civilization will not attain to its perfection until the last stone from the last church falls on the last priest." - Émile Zola

I am of the opinion... (none / 1) (#16)
by skyknight on Sun Oct 23, 2005 at 07:43:16 AM EST

that anything that gets developers to talk to one another is a valuable tool. Good communication skills are crucial to the software development process, perhaps equally as important as good technical skills. Developers ought to be engaging in vibrant discourse with one another throughout the day. Yes, it's important that they be allowed long uninterrupted chunks of time to concentrate so that they can slog through complex problems, but it's also important they be regularly communicating with their co-developers. If you're not having a chat of at least a couple of minutes every day with each person with whom you are working closely, then you're building up to having an explosive argument with them (and management) when the shit hits the fan. More important still, there's no tool that can make a person a good communicator, and most techies are dangerously introverted.

On a related note, I am inclined to think that this is precisely why off-shoring is such a bad idea. Even if your co-workers in India speak perfect idiomatic English, there are still cultural barriers and time-zone barriers that make effective communication essentially impossible. Of course, this isn't to say that there aren't capable people in India that can write amazing software. Rather, it's just a much harder problem than any of the PHBs who think only of man-hour costs will admit. If you want to have a successful off-shore development unit, then you probably need a solid presence established in that country. There is no free lunch, and those who think that there is one to be had are going to find themselves eating glass.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Yeah (none / 0) (#64)
by trhurler on Sun Oct 23, 2005 at 07:00:26 PM EST

This is something I stress to potential employers continually: I'm the kind of guy who actually talks to everybody connected to my work. I keep up with what is going on, and I make better decisions as a result. My communications skills probably aren't quite at the level of my technical skills, but they're far above average for any group of people, let alone just for software people. You'd be amazed how many managers don't understand the value of this(they see it as "goofing off," which some people may in fact do under this guise,) but the ones who do get it value it more than almost anything else.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
definitely underrated (none / 0) (#97)
by Delirium on Mon Oct 24, 2005 at 05:53:47 AM EST

I tend to work on fairly smallish projects in academia, and even here it would be nice if now and then someone that works in the same building and me and knows I'm using their library/API would take 5 minutes and send me an email saying "I'm planning to change [x], [y], and [z], which I don't think will have any major impact but I thought I'd let you know".

[ Parent ]
This ties in with another comment of mine... (none / 1) (#103)
by skyknight on Mon Oct 24, 2005 at 06:37:14 AM EST

namely, that most managers are ill-qualified to judge what does and does not constitute work being done by a software engineer. From outward appearances, it is very hard to tell at any given time the productive state in which they are currently residing. As such, it only makes sense to judge them indirectly, i.e. by the volume and quality of their output. If they are producing quality software at a rate that dwarfs the typical developer by an order of magnitude, presumably it's safe to say that you don't need to worry about them. Even if they are slacking a good chunk of the time, thus only producing 10x as much output as others when they could be producing 20x as much, you should still probably leave them be. :-)

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Yeah (none / 0) (#143)
by trhurler on Mon Oct 24, 2005 at 09:49:56 PM EST

But they never do that.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Yes (none / 0) (#27)
by shm on Sun Oct 23, 2005 at 09:21:07 AM EST

Details here.

[ Parent ]
I can not help but laugh: -1. (1.33 / 3) (#28)
by caine on Sun Oct 23, 2005 at 09:30:39 AM EST

Hm, you come off as having only done small open source projects, and having little clue of the famous "real world". I don't see the point of this article, nor do I find your comments about tools in any way insightful.


So, I take it you're a ClearCase man... (1.50 / 2) (#29)
by skyknight on Sun Oct 23, 2005 at 09:32:33 AM EST

I'm so sorry.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Actually... (none / 1) (#44)
by caine on Sun Oct 23, 2005 at 02:26:09 PM EST

I use all three. CVS at home (old configuration, lazy me), ClearCase is used as main company repository, Subversion for non-intranet connected company developer networks (which we need, for reasons I don't want to expand upon).


[ Parent ]

Hmm (none / 0) (#53)
by trhurler on Sun Oct 23, 2005 at 06:23:30 PM EST

Sounds like you work for some defense contractor. Sorry to hear that.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
No, just with overly paranoid companies. (none / 0) (#107)
by caine on Mon Oct 24, 2005 at 06:59:01 AM EST

We use platform software from companies that ARE defense contractors, and they have some problems grasping the fact that perhaps not all their code needs the same kind of environments.

But it's not that bad, just means you need two computers on your desk while you work with it. One on the encrypted, developer network and one normal on the internet.


[ Parent ]

I see. No Pr0n on the work computer. NT (none / 0) (#140)
by shm on Mon Oct 24, 2005 at 09:46:19 PM EST

[ Parent ]
What's wrong with (none / 0) (#168)
by wiredog on Tue Oct 25, 2005 at 09:24:39 AM EST

working for an arms merchant? The work is interesting and the pay is good.

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
And system test is *real* fun. NT (none / 0) (#170)
by shm on Tue Oct 25, 2005 at 11:58:12 AM EST

[ Parent ]
Uhhh, boss, the system crashed, hard. (none / 0) (#173)
by wiredog on Tue Oct 25, 2005 at 12:49:15 PM EST

There's <classified> all over the landscape.

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
Ouch (3.00 / 11) (#30)
by localroger on Sun Oct 23, 2005 at 09:35:35 AM EST

Re: Educated vs. Trained

I would much rather read the article you write on this topic than this one ;-)

I have an unusual perspective here because I'm both educated and trained, with the latter eclipsing the former as my college days recede into the blurry fog of ancient history. I do remember enough of my education not to resent the pointed remarks about training that might well be aimed at me.

A good example of the distinction is the engineer vs. the service technician. You will never see two groups each with a lower opinion of the other. The engineer considers the technician an ignorant buffoon who's barely capable of understanding the thing he's supposed to install and service; the tech sees the engineer as a buffoon in an air-conditioned office who wouldn't know which end of a crescent wrench to pick up or how to recognize his own creation in its native environment.

And both of them are right.

Since I mainly work with the technicians I get to hear them complaining a lot about dumb-ass things done by engineers. And the sad thing is, they're usually right. When you approach a problem from the design side, it's very hard to see how it will look through the eyes of the guy who has to pick up the pieces after it blows up five years down the line. On the other hand, while they have a lot of good ideas, those techs who are so sure they could design a better mousetrap would fall on their faces if they actually tried. They not only don't know the disciplines necessary to design things from scratch, they don't even know those disciplines exist.

That said, the one thing I have seen which can bring the engineers and techs into lockstep alignment is a suitably stupid PHB. Some people are neither trained nor educated, and when they're the ones with final decision-making authority, make sure you have your hard hat and safety goggles at the ready.

I am become Death, Destroyer of Worlds -- J. Robert Oppenheimer

I think that you need not be offended... (none / 0) (#33)
by skyknight on Sun Oct 23, 2005 at 11:43:37 AM EST

You take far too literal a definition of education and training. It's not a distinction between various bodies of knowledge so much as it is a distinction between how one absorbs and integrates knowledge. I think that someone can be educated without ever having set foot in a classroom. It's a delineation of mind sets, not data sets. I seriously doubt that someone like you, who has been a tinkerer since his high school science fair days and continues to do things like build electronics in his garage could be considered "trained" in any meaningful sense of the word.

The key distinction to make is how an individual integrates knowledge, namely whether new data becomes part of a larger cohesive whole, or is left in isolation and viewed as inexplicable magic. For instance, when I started mucking about with relational databases some time back, I found that when specifying an index for a column that one could specify the type of the index. For example, you could choose "b-tree", "hash", etc... While someone who had never learned about data structures might have had to accept these faculties as magic, I immediately knew that I'd want to select "b-tree" if I suspected that I'd often want to be doing ordered traversals, and that I ought to select "hash" so as to gain extra speed on random look-ups at the expense of speedy ordered traversals. When a database is being slow, I don't need a training course to tell me how to optimize queries. I can instead refer back to knowledge that I have generalized about data structures. It's not magic to me. I know what's happening under the hood.

Your point about the engineer/technician mutual animosity is a good one. Both sides have valid grievances, namely because your typical person on either side is either an ignorant buffoon or a cloud dweller. Technicians often operate at the level of a finite state machine, utterly incapable of adapting to novel situations. Engineers are often completely unaware of the realities on the ground and thus make design choices that, from the perspective of the technician, are insane, misanthropic or downright cruel. Both classes would be happier if technicians would gain a better understanding of the technology that they are using instead of treating it as a black box and engineers were to be more empathetic toward the people who will actually use the things that they create.

I had a professor who drove this point home for me while teaching a bridge building class I took during my sophomore year of undergrad as an elective. He taught part time as an associate professor, had a degree in mechanical engineering, worked for an engineering firm, and apparently had worked in construction jobs before going to university. Basically what he said was that a structure may look nice on paper to an architect, but if you haven't worked construction, meaning you haven't actually had to erect a building, then you're going to end up neglecting little things, like how the hell the construction guys are actually going to put the pieces in place. This stuck with me.

These days, I take user interface design very seriously, aggressively soliciting input from real users by doing user acceptance testing. My typical way of doing this is to drop something in someone's lap and say "here, play with this and tell me if it sucks". Usually their response is, "er, aren't you going to tell me something about it first?" My retort is always "no, that would defeat the purpose of this which is to get your unadulterated impressions".

Lastly, truly there is no good cure for PHBs, except engineering getting them fired. :-)

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Your best writing so far (none / 0) (#41)
by Alien zombie on Sun Oct 23, 2005 at 01:56:29 PM EST

Here you move well from the general to the specific, clearly supporting your points.

Memorable quote:

"It's a delineation of mind sets, not data sets."

I'm intrigued by the theme that technicians are trained, while engineers are educated, but I agree that this is a topic for another article.

[ Parent ]

Thank you... (none / 0) (#42)
by skyknight on Sun Oct 23, 2005 at 02:10:48 PM EST

I'll think about it this week, start assembling ideas, and perhaps write something next weekend. It is indeed an interesting and contentious topic, one that is apt to inflame more than a few people's passions.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Restatement of mapper vs. packer (none / 0) (#88)
by k31 on Mon Oct 24, 2005 at 01:45:42 AM EST

This whole discussion reminds me of the "mapper vs. packer" threads on the programmer's stone mailing list. Its almost officially dead now, but in the archives is a lot of discussion and there's also the  website with the original Programmers' Stone website which introduces the concept.

[ link: http://www.reciprocality.org/Reciprocality/r0/ ]

There's also, apparently, something about farmers vs. hunters; which is more classic and well-known, but I haven't read much on that.

In any case, an "educated" person would be akin to a mapper, and a "trained" person, a packer. I won't bother to restate the explainations in the origional document but it might be worth your while to check into it.

Nonetheless, that article is worthwhile esp. with respect to how the education system can actually encourage/produce "educated", rather than "trained", people.

Your dollar is you only Word, the wrath of it your only fear. He who has an EAR to hear....
[ Parent ]

Technicians vs. Engineers... (none / 0) (#136)
by beergut on Mon Oct 24, 2005 at 05:47:45 PM EST


I don't think it's an issue of "Technicians are Trained" and "Engineers are Educated" [what beautiful alliteration, though!]

Rather, you need to have experienced both sides of the coin, at least to some degree, to realize the full implications of your design [as an engineer] or to realize the tradeoffs in the designs you would criticize [as a technician.]

Because I have swamped out toilets, I do not spit chewing gum into toilets and urinals. It just isn't polite, and it sucks to clean them out. Assholes who have never done these things do not understand the full scope of their actions and how they affect others [incidentally, such people should be brutalized.]

No man escapes when freedom fails; the best men rot in filthy jails.
Those who cried, "Appease! Appease!", are hanged by those they tried to please.
[ Parent ]

Much clearer (none / 0) (#46)
by localroger on Sun Oct 23, 2005 at 04:38:52 PM EST

I definitely want to read the article you write on this subject...

You're right, I do tend to put new ideas in context within a large framework instead of taking them as Gospel. And I am open to new ideas, although I'm an older dog now and reluctant to give up those tricks I'm most familiar with. This has left me with the language and technique chauvanisms people here are *cough* very familiar with.

I would get along well with your bridge building prof. In fact, so would the people I work with. If there had been more moments like that in my own college education, I probably would have made more of an effort to finish my degree. (As it happened, I really only had those moments in electives like Philosophy and Eastern Religions which did not even count toward my degree.)

I agree completely w/r/t user interface design -- you cannot design a UI to spec, period. I know of several many examples where companies did this with disastrous results. One reason my work is in demand even though I'm not up to speed on all that cool new stuff is that my machine and human interfaces work reliably. And the only way to make that happen is to play with them, tweak, try them out, and tweak some more until everyone who touches them finds them obvious and natural.

And blessed are those companies where the engineers get the PHB's fired instead of the other way around. A long time ago I had a dispute with the boss's son, who had decided managing the "computer department" (aka me) was a prestigious place to be. He wanted me to install HP calculators in NEMA 4 enclosures to use as controls in a chicken plant. I told him I could make it work in the office, but it might not work in the field. He insisted. I made it work in the office, but of course those little battery gizmos don't like a lot of electrical noise and it failed spectacularly in the field. End result: The boss fired his own son and gave me a promotion.

And people ask me why I still work here :-)

I am become Death, Destroyer of Worlds -- J. Robert Oppenheimer
[ Parent ]

I am the annoyer of worlds... (none / 0) (#34)
by Alien zombie on Sun Oct 23, 2005 at 11:45:40 AM EST

but seriously, I've always appreciated talented technicians and enjoyed when they play stump-the-stupid-engineer with tricky troubleshooting problems. One interesting case involved Fluke DMM's that gave spurious current readings because of an apparent interaction with the switching supply of a circuit-under-test. Some cheaper models gave the erronious readings, so we had to specify that only certain models be used for that functional test.

[ Parent ]
Hmm (3.00 / 3) (#61)
by trhurler on Sun Oct 23, 2005 at 06:55:49 PM EST

I have an unusual perspective here because I'm both educated and trained,
In the sense you mean, everybody is to some extent. In the sense skyknight means(I think,) not so much. It isn't really about whether you learned in a classroom or in a seminar or on the job or whatever. It is much more about your approach to learning. "Educated" people enjoy learning, and learn in depth. "Trained" people are basically taught a set of talking points and a set of operations to perform and so on. How vs why. If you understand why, the how is almost irrelevant. If you don't, then the how is almost useless. You strike me as more educated than trained.

Honestly, anyone who hasn't worked with multiple different tools of any given kind ought to keep his mouth shut about the subject. Anyone who has only used(in depth) one operating system knows nothing about operating systems. Anyone who has only used one programming language does not know how to program - period. Anyone who hasn't used a couple of version control systems ought to just shut up about them. And so on. This is because of my final point here:

Contrary to the elitest rantings of cheerleaders for universities, universities do not educate you. They cannot educate you. The intellectual world has grown so large that there is no way to educate people in a few hours a week worth of lectures, labs, and so on. It cannot be done. If you spent four years taking 18 hour courseloads of literature alone and aced it all, you would still be ignorant of literature as a general subject. That's just a fact of the vastness of literature. Well, in technical fields, it gets worse, not better.

In technical fields, there is a hiring solution: do not bother with people who have really high GPAs unless they have matching experience. A high GPA and no experience is almost guaranteed to be a loser. Do not bother with people who haven't spent time on a job or developing projects of their own, whether in software, electrical engineering, or whatever. The kind of people you want have done these things. They may or may not have gotten far with them, but they have done them. When you talk to these people, assuming you have a deep understanding, you will realize that they also have this understanding, and you don't have to ask "hard" questions to figure this out. On the other hand, lots of people with mediocre records in school have the experience and the understanding, and you can hire these people with fair confidence. They may be somewhat odd on occasion, but if you make them comfortable, they'll produce for you time and again.

Universities are great places to learn, but you don't go there to "get educated." People who believe that are morons. There are plenty of PhDs who are useless in their own fields. There are plenty of professors in my field who couldn't do my job to save their lives. Many of them taught me. Sure, I learned things from them - but the key is, I could do their job with or without that degree, but they will never be able to do mine. Ultimately, education is about your attitude towards what you're doing.

Why do I know more about philosophy than most graduate students in the field? Because I enjoy the subject matter and read and think about it as a hobby. Why have I forgotten more about programming best practices than my university instructors will ever know? Because I do this both professionally and as a hobby - where most people learn something and go with it, I learn new stuff just because I want to know how it works. Why do I know more about the workings of automobiles than most professional mechanics? Because I desire to know, and I went out and learned, and am still learning. The myth that you can be "good at everything" needs to die. No, I'm not an expert on any kind of literature. I am not an expert on any kind of history(although I do know quite a lot of history.) I am not an expert on most fields. I know quite a lot about most things compared to most people, but that's only because most people are shockingly ignorant.

In short, the myth of the well rounded education needs to die. A well rounded education is the work of a lifetime, not four years. No prestigious name or ridiculous tuition bill can change that. Sure, I have a degree. I had to have one, because it is used as a litmus test. But what you don't realize until you've been in on a couple of hiring decisions is this: they don't use your degree to see if you know the field. They use your degree as an indicator that you can probably read and write. Yes, that's literally how bad it really is.

Education is an attitude applied over time. Nothing less will achieve it, and nothing more is necessary.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Here's a no-brainer: (3.00 / 3) (#114)
by it certainly is on Mon Oct 24, 2005 at 10:09:25 AM EST

don't let some guy suffering his mid-life crisis make hiring decisions, especially not if he has a bug up his ass about universities (I don't know, maybe a university killed his father or something). His baseless prejudices will drive off any form of talent his narrow mind can't immediately recognise.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

Heh (none / 0) (#144)
by trhurler on Mon Oct 24, 2005 at 09:51:34 PM EST

Do you work in a technical field? If so, have you ever met 4.0 students with no experience? Yeah. They're worthless. I'd hire a dozen guys with 2.5 GPAs, 3.0+ in major, and at least a few months of real work experience plus some sizable projects from classes or hobby work to show off before I'd hire a single professional test taker.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Packers vs Mappers (none / 0) (#255)
by gidds on Thu Nov 03, 2005 at 05:21:26 PM EST

That's exactly the distinction made very well in The Programmer's Stone. Well worth a read.

(It really struck a chord for me, but I don't know of anyone else who's read it, which surprises me. Maybe it's coz they went on to extend that fairly concise, rational, and insightful piece into a bizarre, sprawling, pseudo-scientific mess... Unless anyone thinks that the rest of the Reciprocality site makes any sense?)

[ Parent ]

The Programmer's Stone (none / 0) (#82)
by BenJackson on Sun Oct 23, 2005 at 11:05:11 PM EST

Re: Educated vs. Trained

I would much rather read the article you write on this topic than this one ;-)
The article you're looking for is The Programmer's Stone.

[ Parent ]
Perforce is fighting The Last War (none / 1) (#31)
by QuantumG on Sun Oct 23, 2005 at 09:40:38 AM EST

A centralized repository for source control is a model that has done more damage to open source than good. If you want to see the ultimate end result, look at OpenBSD. Brilliant workers making quality software at a snail-like pace whilst excluding anyone new from contributing. If you want to see how it should be done, look at the decentralized revision control systems. The most noted being Bazaar and Bazaar-NG. Massive parallel development is the order of the day, and the only way to do that is with decentralized workflow tools.

As for proprietary development.. it's a hopeless cause. Proprietary software will never do everything the customers want. It will never be bug free. It will always require a dedicated workforce of people to install, upgrade and maintain it. As soon as open source solutions start competing on an even playing field with it proprietary software will fail. The only hope of proprietary software developers is to make sure the playing field never becomes even, at the expense of customers.

Gun fire is the sound of freedom.

never be bug free? hahaha (3.00 / 2) (#40)
by boxed on Sun Oct 23, 2005 at 01:33:46 PM EST

Can you possibly make it more obvious you're totally clueless about what programming entails?

[ Parent ]
What? (3.00 / 3) (#52)
by trhurler on Sun Oct 23, 2005 at 06:21:46 PM EST

You must be on crack. Considering their code quality, the OpenBSD team moves at a lightning-quick pace. The reason they're so unfriendly to newcomers is not their tools - it is that Theo is a right bastard. But, I've had beers with him, and he's a damned good bastard if you ask me. Nuts politically, but then, he's not a politician.

There's a reason people want that central control though. Frankly, your mythological notion that if we just lose all control of something, quality will go up is not warranted. It has no basis in fact.

No software will ever be bug free. If you believe otherwise, you're nuts. Odds are there are bugs in hello world. (In the libraries, of course:).

The idea that open source can compete with proprietary software onall fronts is nuts. Open source is the end state of a given software field. As a given category of software becomes mature, well understood, and commodity-ish, it makes sense to go to open source, and this will further its development. BUT, in all but a few cases, truly new software niches are poorly served by open source. They need huge investments of time and money for a return that is off in the distant future. Few people understand them, and fewer still actually need or want the results. This sort of thing never gets done in an open source world.

By the way, if you don't believe me about OpenBSD, look at what they've added in the last two years and compare it to what most commercial systems have done in the last two years. They're rapidly killing any claim commercial Unices and traditional network device embedded systems have to any sort of superiority.

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
in some cases, open source can work (none / 0) (#95)
by Delirium on Mon Oct 24, 2005 at 05:51:03 AM EST

Innovation has happened in open source, if there's some funding source for it. For example, the first fully-functional and widely-used microkernels, Mach and L3/L4, were both developed as open source by universities, and only after some years were picked up by industry (e.g. Mac OS X).

[ Parent ]
Hardly the same thing though (none / 0) (#148)
by jongleur on Mon Oct 24, 2005 at 11:58:32 PM EST

Those university projects were funded and organized, no doubt guided by a professor or a couple of geniuses who could put in real time. They weren't done by the usual way 'open source' is, a free-for-all of people who lose interest after a while (I haven't yet participated in one, this is just an impression).
"If you can't imagine a better way let silence bury you" - Midnight Oil
[ Parent ]
That's my big argument against people who say... (none / 1) (#151)
by skyknight on Tue Oct 25, 2005 at 05:41:59 AM EST

that everything can be open source. There are many problem domains that just aren't sexy enough and that require not just the thinking of interesting thoughts but also the duration of a long hard grind of hammering out the details. To endure that grind, people typically need money to keep them motivated.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
yeah, I agree with that (none / 0) (#167)
by Delirium on Tue Oct 25, 2005 at 09:21:20 AM EST

I do think major innnovation in open source development needs a dedicated core team that has a source of funding.

Or a core team with no funding and a really long time, like Enlightenment. (Yeah, it's taken forever, but they've built up a pretty impressive set of foundational libraries in the meantime, and e17 might even be out in a year or so.)

[ Parent ]

ClearCase? (3.00 / 2) (#32)
by t1ber on Sun Oct 23, 2005 at 11:42:10 AM EST

As a professional systems engineer, I see that ClearCase (like commercial CVS) is missing.

Not that it's a huge loss, but it's got some snazzy features which CVS and Subversion lack. However, it still uses broken CVS logic and extends this to the developers desktop through shell extensions. Through this, it also extends those infuriating problems CVS has directly to your workstation. I manage to keep my hands out of the serious code which is reserved for the developers, but I still hear the Cries Of The Damned occaisionally. The latest wonderful ClearCase Cluster Cockup came from a recent upgrade which forces you to do the checkout-copy-delete-checkin file moving dance locally. It is quite possibly the worst thing ever. I understand why they do it: The idea is to keep the files in a location consistant to the ClearCase project layout. However, this makes reorganization and refactoring very hard.

I've been toying with the idea of just grabbing a NAS server and having everyone NFS mount the project.

And she said...
Durka Durka Mohammed Jihad
Sherpa Sherpa Bak Allah
Hadji girl I can't understand what you're saying.

What subversion lacks.... (none / 0) (#228)
by ckaminski on Fri Oct 28, 2005 at 12:59:30 PM EST

About the only thing Clearcase has on subversion right now is ViewFS, and even that is marginal, since many platforms support remote mounting of WebDAV and Subversion DEFINITELY works over that.  It's not perfect, or fully-featured, but it's workable.  

Even if I had Clearcase freely given to me, I'd choose Subversion instead.  When subversion is coupled with SVK for distributed development, Clearcase is clearly inferior.

[ Parent ]

No big deal. (1.33 / 3) (#35)
by Lemon Juice on Sun Oct 23, 2005 at 12:14:24 PM EST

really isn't a big deal at all.

-1 Does not mention 'darcs' n/t (1.50 / 2) (#45)
by Vs on Sun Oct 23, 2005 at 03:57:44 PM EST

Where are the immoderate submissions?
Maybe (none / 1) (#51)
by trhurler on Sun Oct 23, 2005 at 06:16:55 PM EST

That's because nobody cares about it. :)

'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Re: darcs (none / 0) (#131)
by Vs on Mon Oct 24, 2005 at 04:30:09 PM EST

Hehe, enough people care to make me at least start wondering (worrying?) about it, too.
Where are the immoderate submissions?
[ Parent ]
Don't. (none / 0) (#229)
by ckaminski on Fri Oct 28, 2005 at 01:00:24 PM EST

Subversion + SVK.  You'll never regret it.

[ Parent ]
Pathetic (1.28 / 7) (#62)
by Makenzie Smith on Sun Oct 23, 2005 at 06:59:35 PM EST

All the nerds on the Internet who think software actually matters.

As opposed to the genie taking your tiny little (none / 0) (#73)
by shm on Sun Oct 23, 2005 at 09:39:31 PM EST

thoughts and sending them across to the whole world.

You need some education and training before you get good at trolling.

[ Parent ]

Was your POS comment sent in via snail-mail?[nt] (none / 0) (#92)
by mirleid on Mon Oct 24, 2005 at 05:00:29 AM EST

Chickens don't give milk
[ Parent ]
See my reply to localroger below. (2.50 / 2) (#65)
by trhurler on Sun Oct 23, 2005 at 07:04:20 PM EST

Also, file locking is the worst sort of uselessness in version control. If you go to a two stage process where you have the source control used by developers and then they periodically release a snapshot into a release management system, then locking makes sense, but at that point you're locking the entire repository(on both ends,) rather than just individual files.

Incidentally, the two-repository system mentioned above is a fantastic way to do software releases, but almost nobody ever does it.

'God dammit, your posts make me hard.' --LilDebbie

Locking makes sense (none / 0) (#179)
by kosuri on Tue Oct 25, 2005 at 04:10:16 PM EST

for unmergeable files. If you and some bozo in Brazil are working on the same PNG image without knowing it ("not knowing it" is always the case when there is no file locking), how the hell do you propose to merge your changes together?

Me, I'd rather have file locking for those types of files. That way, bozo in Brazil knows what I'm doing and vice versa.
I'm glad that when this story goes down this stupid comment will go with it. -- thankyougustad, 11/23/2005
[ Parent ]

However (none / 1) (#194)
by zakalwe on Wed Oct 26, 2005 at 05:49:26 AM EST

Strict locking is no more useful than advisory locking in this case, since the real issue is communication.  (Admittedly, I don't know if svn has advisory locking either - CVS does though)

For code though, I agree with the OP - locking just adds hassle for no real benefit.

[ Parent ]

svn lock (none / 0) (#198)
by kosuri on Wed Oct 26, 2005 at 10:39:47 AM EST

Subversion 1.2 has locking that is "strict", but I put strict in quotes because, by default, anyone can break any lock of any user. But as long as a file is locked, the server won't allow you to commit that file.

Of course, it's trivial to make it so that ordinary developers cannot break each other's locks, but by default, like I said, any lock can be broken by any user with commit access to the repository. For more than you ever wanted to know about subversion locking, have a look here.
I'm glad that when this story goes down this stupid comment will go with it. -- thankyougustad, 11/23/2005
[ Parent ]

I'm not sure I quite understand your meaning... (none / 0) (#213)
by skyknight on Wed Oct 26, 2005 at 09:57:51 PM EST

How is this different from making a release branch and then having only certain people working in that branch?

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
change the API functionality? (2.50 / 2) (#66)
by sal5ero on Sun Oct 23, 2005 at 07:20:58 PM EST

Nothing could be further from the truth. If someone is working on file A, and a co-worker is working on file B, and file A includes file B, depending on the API that it exports, then the benefits of file locking to you are precisely NOTHING. The functionality provided by file B could change out from under the developer working on file A, and unless the developer working on file A is communicating with the developer working on file B, then he is hosed. That's all there is to it.

are you saying co-worker might change (not just add to) the API on file B? or change the result of calling the API with certain inputs? WTF?

-1 CVS SUCKS!! (1.14 / 7) (#85)
by Lemon Juice on Mon Oct 24, 2005 at 12:56:31 AM EST

I fucking hate CVS. I've had so many problems with it I don't know how anyone can use it.

shit is coming out of my arse as i type (1.54 / 11) (#93)
by bg ex plus alpha on Mon Oct 24, 2005 at 05:06:41 AM EST

I see that you're an Eclipse user. (1.33 / 3) (#105)
by skyknight on Mon Oct 24, 2005 at 06:45:42 AM EST

I'm so sorry.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
this is the type of thing I mock you for (3.00 / 3) (#111)
by speek on Mon Oct 24, 2005 at 07:53:05 AM EST

Because it's the type of thing one says in order to look smart in front of the other computer geeks.

al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Eclipse (none / 0) (#121)
by Nasarius on Mon Oct 24, 2005 at 01:37:05 PM EST

Not to get into holy wars, but Eclipse really is the best thing since sliced bread when it comes to Java. Its refactoring abilities and continuous background compilation make it a joy to use. For C++, not so much. I'll use a vim/make/screen combo instead. It still results in more wrist strain than a good IDE, though. If you can't see how they can be better for large projects, you're just a zealot, and it's not really something to be proud of. Good article, though.

[ Parent ]
So that's what Subversion is (2.50 / 6) (#115)
by BottleRocket on Mon Oct 24, 2005 at 11:34:28 AM EST

I like this article, cuz it encourages the pretense that kuro5hin is technology-oriented. Also, as a linux user who doesn't code, it's nice to be told what to think about new stuff to appear well informed.

$ . . . . . $ . . . . . $ . . . . . $
. ₩ . . . . . ¥ . . . . . € . . . . . § . . . . . £
. . . . * . . . . . * . . . . . * . . . . . * . . . . . *
$ . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . $
Yes I do download [child pornography], but I don't keep it any longer than I need to, so it can yield insight as to how to find more. --MDC
$ . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . $
. . . . * . . . . . * . . . . . * . . . . . * . . . . . *
. ₩ . . . . . ¥ . . . . . € . . . . . § . . . . . £
$ . . . . . $ . . . . . $ . . . . . $

Who gives a fuck? (1.71 / 7) (#116)
by bighappyface on Mon Oct 24, 2005 at 12:03:37 PM EST

This is kuro5hin, not Slashdot. Submit it there.

Quick note on file locking (none / 1) (#117)
by Trevasel on Mon Oct 24, 2005 at 12:14:13 PM EST

First off, it is a mechanism of communication between programmers and artists. Also, in the game development community as well as others, I imagine, it is mostly used for binary files such as game assets where there is no opportunity for merging and on many occasions your data architecture doesn't have enough granularity to support fully independent operations by all of the assett developers. In this situation it is essential.
-- That which does not kill you only makes you stranger - Trevor Goodchild
SVN, Educ vs Train, Codeville (3.00 / 2) (#119)
by OldCoder on Mon Oct 24, 2005 at 01:12:23 PM EST

Interesting work on source control is being done at codeville.

It was the self-trained who discovered the knowledge and taught the educated. I've known exceptional people in both categories. As a developer, I have learned, for example, that I am not a talented tester. I have met some people who are and was awed. Not envious, but awed. Most testers aren't like that. I've also known engineers who were absolutely fantastic technicians and were the people the techs would go to when stumped. Most engineers aren't like that.

Some topics, even in Software Engineering, are not Settled Questions, and we are all just trained a little differently.

Mule-headed change-averse victims of Baby Duck Syndrome can pop up anywhere. I've known some mule-headed ducks in all walks of life.

Subversion has some unpleasant quirks on Windows. A normal way to start a project is to fire up the IDE and code for a while. When you have some files to be protected you try and put the directory under source control. When you put a directory under subversion source control you:

  1. Must make a new repository for a new project, lest your new project acquire the version number of your pre-existing projects. This would be okay if the documentation hadn't suggested sharing repositories across projects in the first place.
  2. Check in everything, including all the files your IDE made that you don't know much about. Some of the IDE files could be non-text (binaries).
  3. Check out the stuff you just checked in. But to a different directory. This means that your IDE files are duplicated and may possibly refer internally to the original directory. Depending on the IDE.
The wave of the future is for source control to be more tightly integrated with IDE's, build systems, and release management. IDE integration will make sure that only the stuff that needs to be saved will be saved and .objs and other temp files are automatically not archived, for example. Build systems really want to know what symbols changed rather than having to go on a file by file basis. Many is the time one tiny change triggered an overnight build. Change control, release control, configuration management and all that occupy too much time and effort. Sometimes testers and code reviewers have a real need to add comments (or hyperlinks) to source files. But if the source control system can't tell a comment from a statement, this is just too difficult.

The proprietary software firms continue to deliver innovation to the user at a brisk clip. Including innovations that originate elsewhere, for sure. But competitive firms like Microsoft, Oracle, and Apple need to provide a product a cut above the others. A look at the projects on sourceforge, like the 10 most active, shows a great deal of OSS is trying to deliver capability already available elsewhere. The OSS movement just doesn't have the moxie and the organization to try to deliver Avalon, for example.

Also, are we really sure that Subversion isn't just a stalking horse for Stalinism? (insert generic smiley)

By reading this signature, you have agreed.
Copyright © 2004 OldCoder

z (none / 0) (#174)
by GotoHospital on Tue Oct 25, 2005 at 12:54:35 PM EST

integration is good, something a lot of *nix people don't recognize. Integration of programs can provide features that aren't available otherwise.
nested¢ evolution is still interesting. talk.origins faq.
[ Parent ]
Not really. (none / 0) (#180)
by GhostfacedFiddlah on Tue Oct 25, 2005 at 05:05:37 PM EST

Integration provides features that aren't available otherwise at the cost of making those features non-portable and breaking compatability with other systems.

It's a tradeoff.

Ideally integration would be provided via a standardized, portable API - such that features could be integrated into any similar program.  Unfortunately, that opens up another tradeoff in that it increases development time writing standardized, portable code, and there's a case to be made on the business end to keep your good stuff proprietary.

[ Parent ]

Other SVN warts... (none / 0) (#128)
by sudog on Mon Oct 24, 2005 at 03:51:13 PM EST

It also unofortunately suffers from a lack of merge history, slow backend operation, and doesn't scale so well. :(

Good as an OSS tool, probably not so good for large-scale operations, where intelligent merging can often be a necessity.

This is not to say it doesn't have promise of course--it's getting there. I just think it's not quite there *yet.*

Out of curiousity... (none / 0) (#190)
by skyknight on Wed Oct 26, 2005 at 05:13:27 AM EST

how long ago did you start using it? Personally, I had people badgering me to start using it back in 2002-2003 but said "no thanks" because I had the conception of it being bleeding edge and not ready for prime time. I waited until this year to start using it, and I've been pretty happy. If you haven't tried it recently, you might want to look at it again. One of the criticisms oft levied against SVN is that it went live too soon, and that's probably a fair jab, but that doesn't mean that it's bad now.

If you would, please describe some of the merging problems you have had. I'd be interested to know, if just so I can be on the look out for them myself.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
It keeps no merge history. (none / 0) (#243)
by sudog on Sun Oct 30, 2005 at 12:43:03 PM EST

.. and doesn't do ancestry searches for three-way merge base detection.

Also, as a result of its binary diff, its scaleability is atrocious. CPU time is limited in an enterprise environment: disk space is not. This is part of the reason why the tool has been designed for the home user, but not the enterprise.

[ Parent ]

IAWTA (none / 0) (#133)
by actmodern on Mon Oct 24, 2005 at 04:46:46 PM EST

About the whole emacs and vi thing. I've seen people use the most craptastic shareware editors to have ever graced the modern computer. Death would come as a comfort to these hordes.

LilDebbie challenge: produce the water sports scene from bable or stfu. It does not exist.
I've had to tolerate a co-worker using pico... (none / 0) (#191)
by skyknight on Wed Oct 26, 2005 at 05:14:15 AM EST

For Christ's sake... PICO!!!

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
your a n00b (none / 0) (#199)
by army of phred on Wed Oct 26, 2005 at 10:41:43 AM EST

All the real forum timewasters know that you either advocate vi _or_ emacs but NEVER BOTH!

All this means is that you are the worlds biggest poser wannabe. Sorry to ruin your troll but it had to be revealed.

"Republicans are evil." lildebbie
"I have no fucking clue what I'm talking about." motormachinemercenary
"my wife is getting a blowjob" ghostoft1ber
[ Parent ]

my a n00b indeed (none / 0) (#214)
by skyknight on Wed Oct 26, 2005 at 10:07:53 PM EST

I could Emacs you under the table.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
What a loser (none / 0) (#235)
by rusty on Sat Oct 29, 2005 at 01:44:04 AM EST

Who uses pico anymore, now that we have nano?

Not the real rusty
[ Parent ]
Well, sure... You and I know this... (none / 0) (#236)
by skyknight on Sat Oct 29, 2005 at 08:37:02 AM EST

The thing is, if someone is foolish enough to use pico when nano is available, then you might just as well have an argument with a pile of bricks. It's just that hopeless. Now, if you'll excuse me, I need to yell at my wall.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Your tagline (none / 0) (#222)
by bigcalm on Thu Oct 27, 2005 at 07:41:45 PM EST

I was wondering if you know what your tagline means and implies? I'm not against personal entertainment, mind you, just curious.

[ Parent ]
CVS vs commercial, SVN vs commercial (none / 0) (#147)
by jongleur on Mon Oct 24, 2005 at 11:52:58 PM EST

When you used CVS were you dismissive of commercial systems as well? How do you know there aren't some killer features that would make you feel toward SVN that you do now toward CVS and commercial ones?
"If you can't imagine a better way let silence bury you" - Midnight Oil
When I used CVS... (none / 1) (#154)
by skyknight on Tue Oct 25, 2005 at 05:58:51 AM EST

I was greatly frustrated by the things that it lacked, but for the most part I tolerated them, probably because CVS was the first version control software I used and thus for at least part of my use of it I didn't have any degree of version control sophistication myself. For the most part, though, I'm not coming out to bat for Subversion over various commercial tools because it has features that various others don't (it does) but rather because it seems to eschew reliance on misfeatures as a selling point. Every time some clown at work derides Subversion as not being a "real" tool, it is invariably because they want a sophisticated file locking system. This irks me because not only is file locking stupid, but when I explain to them in excruciating detail why it is stupid, the ones who have been poisoned by commercial offerings are too thick to see the light.

Something that I think would be killer is if there were a suite of tools that did an amazing job integrating an editor, a bug tracking system, a version control system, and a project management system. To my knowledge, no such thing exists. I get the picture that there are good integrations of bad tools, and bad integrations of good tools, no good integrations of good tools. As I said at the end of my OP, it's probably going to be decades before we have something really good in this regard. :-/

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Gobby (none / 0) (#171)
by rebelcan on Tue Oct 25, 2005 at 12:00:42 PM EST

I don't know if this interests you at all, but for situations like the one you detailed in your article ( developer A working on file A which depends on file B, which developer B is working on ), I think Gobby ( http://gobby.0x539.de/ ) would probably come in handy.

God is dead -- Nietzsche
Nietzsche is dead -- God
but Zombie Nietzsche lives! -- Zombie Nietzsche
[ Parent ]
Wrong, I'm afraid. (none / 0) (#176)
by sudog on Tue Oct 25, 2005 at 02:15:25 PM EST

Strong file locking is not the feature that most enterprise-class customers are missing in Subversion. It's its scalability (or lack thereof) and its lack of commercial-grade merging.

[ Parent ]
"Enterprisy" stuff (none / 0) (#209)
by unDees on Wed Oct 26, 2005 at 09:37:49 PM EST

Some "enterprisy" things like ClearCase also have sophisticated, wildcard-based version selection: "I want all my .h files from the 'foo' branch and all my .cpp files from the 'bar' branch." Some people swear by that stuff. Me, on the rare occasions (maybe once?) when I've needed to build a Frankenstein's monster of a working copy with files from multiple tags/branches, it's actually been harder to figure out the right wildcard expression than it would have been just to click on the files that were exceptions and say, "These. These are the ones I want from the 'foo' branch. The rest can be from 'bar.'"

Some folks are sold on the idea of replicating repositories from one office to another and are convinced that only ClearCase can do that. I've never evaluated that claim, but I retain a healthy skepticism towards it.

I don't know whether or not ClearCase is enterprise-friendly, but it sure is developer-hostile. What good is industrial strength (or the perception of it) if the developers themselves lose productivity wrestling with a slow, crashy, pestering tool that enforces its own byzantine directory structure?

Your account balance is $0.02; to continue receiving our quality opinions, please remit payment as soon as possible.
[ Parent ]
I agree re:ClearCase (none / 0) (#242)
by sudog on Sun Oct 30, 2005 at 12:40:26 PM EST

It unfortunately suffers from a terrible lack of scaleability, and an extreme administrative requirement. What is the recommended admin:user ratio again? Something like 1:100?


[ Parent ]

educated Vs trained (none / 0) (#177)
by nietsch on Tue Oct 25, 2005 at 02:31:53 PM EST

These two groups are not mutually exclusive. The educated person needs some place to pick up new knowledge, tha place may well be a training, or a teach-yourself book (probably has enough experience to avoid the really nast examples of that category). So the ducated person may appear trained on some points.
On the other hand, the 'trained' person most likely had a formal education too.
And since you have painted the picture so very black and white, I' doubt it if anyone would call himself 'trained' by your definition.
I think that is because your definition is wrong: you ment to divide by: people I like(and agree with me) and people that do not agree with me(And I don't like). You are right in the file-locking example, but I shure do not wish to have a disagreement with you.

Try reading... (none / 0) (#187)
by skyknight on Wed Oct 26, 2005 at 04:34:55 AM EST

my reply to localroger's comment below.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
SVN 1.2 DOES HAVE LOCKING! (none / 0) (#178)
by n8f8 on Tue Oct 25, 2005 at 03:08:46 PM EST

Per the Release notes. Of cource you need to make a commit script to automatically lock a file.

Sig: (This will get posted after your comments)
SVN taggging sucks (none / 1) (#181)
by dxh on Tue Oct 25, 2005 at 06:03:05 PM EST

The Tagging and Branching in SVN sucks compared to CVS.  The main result is because of SVN's very simple-minded approach to SVN's lack of the ability to keep track of each file independently.  It takes a lame-brainded approach at versioning the whole project at once.  

SVN can only do a branch on a WHOLE copy of the repository, and you can't copy a single file from branch to branch, you have to totally merge them etc.. very cumbersome and stilly.

In CVS I can use tags and branches to easily make a promotion model, by having all development go on in the HEAD of the tree, and by tagging individual version of files as being say "PROD", or "TEST".  You can then take a fix you develop in version 1.6 of file2.c and just "move" the PROD tag from version 1.5 to 1.6 of THAT FILE, but leave all the other PROD files the way they were.

This is very powerful in the right hands and for those that have a large team and want to inforce some type of software configuration management and promotion model methodologies.

SVN is blah.  Some nice features, but you loose to much to use over CVS.

That and the fact it takes an army of people to get SVN to work on a non-Linux platform because of its like 10000-different dependencies on other beta-quality open source software.

I just installed SVN on Win2K3 today (none / 0) (#182)
by zrail on Tue Oct 25, 2005 at 07:53:21 PM EST

It took about two hours to get everything setup properly, and that included waiting on the DNS admin to allocate a new name for the server.

This install uses Apache 2.0.54 (also installed today and included in the time above), Subversion 1.2.3, and an SSPI authentication module for Apache so users can authenticate against Active Directory.

[ Parent ]
Um... (none / 0) (#189)
by skyknight on Wed Oct 26, 2005 at 05:09:35 AM EST

I'm perfectly happy using svn from the command line. It takes all of five seconds to configure it: "svnadmin create [path]"

This strikes me as a bizarre criticism of SVN. For one thing, it's possible to have such problems with any software that has environmental requirements, like waiting on sysadmins to install or configure stuff. Secondly, a one time cost like that ought to be dwarfed by the time line on which you'll use something like a version control tool, as well as the sheer volume of use and utility.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
You misunderstand me (none / 0) (#208)
by zrail on Wed Oct 26, 2005 at 07:48:47 PM EST

I was trying to debunk the theory that Subversion is hard to install. Two hours is no time, especially considering that I was figuring everything out as I was going along, including how I wanted permissions setup. I think it's fantastic.

[ Parent ]
Er... what? (none / 0) (#188)
by skyknight on Wed Oct 26, 2005 at 05:06:18 AM EST

Are you kidding me? You can definitely use SVN to properly manage a production environment.

When I want to push code out the door, I make a release branch. This snapshot gets dropped into a staging area, and after it has been proven stable in there it is pushed out to the production environment. If there is a problem discovered with it, the fix is made in the branch and pushed out. It is then determined whether the defect is present in the trunk, in which case a merge operation is done, bringing the fixes done in the branch back into the trunk. This is a perfectly sane practice that is followed by many people.

Your way of doing things actually strikes me as being somewhat foolish. Developers pushing code into the trunk of the repository are banging out features wholesale, not thinking about the production environment. The change that they make for a given revision might not only fix a release snapshot bug but also change some other stuff. In the production environment you definitely don't want to go borrowing trouble by pulling any more code than you absolutely have to pull into a snapshot. You should be effecting the fix and nothing more, because if you're pushing out additional new features beyond the bug fix, then you're mitigating the benefits of having done extensive testing. If you're doing your bug fixes in the release branch and then merging them back into the trunk, you have total control over the release branch. If you're relying on fixes that were made in the trunk, then you have no such fine-grained control.

Also, your complaint about Subversion having repository wide revision number is absurd. This feature allows commit operations to be viewed as change sets as opposed to commissions of individual files. This is fantastic for the simple reason that you don't need to resort to any ad-hoc measures to figure out the total set of stuff that changed along with the changes to any given file. As far as I am concerned, you don't lose anything by doing this. If you really want to do it, you can commit files individually. It's just silly.

Also, your comment that you can't do things at the file level granularity with branches is just bizarre. Do you not realize that you can merge the contents of individual files? All around, you strike me as not having taken the time to learn Subversion.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Learn it before you flame it (none / 0) (#195)
by schrotie on Wed Oct 26, 2005 at 09:00:22 AM EST

I addition to the other answers to your comment:
I think you can indeed do the tagging/branching thing of your cvs example in svn. You can always create "tags" in svn of single files or the whole tree or whatever by copying them - at next to no cost mind you. You can merge or overwrite single files, subdirectories or the whole tree with other versions. Which is exactly what you want to do, if I understand you correctly. And finally you can have heterogenous "tag" arrangements in you working directory. You can e.g. use "PROD" for everything except for two (or however many or few) files which you are working on or whatever. When updating or committing from such mixed work directories, the right thing (tm) happens.

The subversion approach is immensely powerful, yet very simple to grasp.

I introduced svn in my department after testing it for some time. The migration (including the migration of our cvs repositories including history) was a breeze. Our server is Linux, but many of the clients are Windows. No problems at all. Getting the cvs stuff to work on windows was a hell of a lot harder, because cvs does not really include server functionality, and for security reasons we had to tunnel cvs through ssh, which was a bitch to get up and running on Windows.

I guess you got a lot of "training" in cvs, didn't you?

[ Parent ]

*ZING* (none / 1) (#210)
by skyknight on Wed Oct 26, 2005 at 09:44:26 PM EST

I guess you got a lot of "training" in cvs, didn't you?

Bwahahaha... You have hit the nail squarely on the head my friend.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
IntelliJ plugin? (none / 0) (#184)
by Milo Minderbender on Tue Oct 25, 2005 at 09:06:20 PM EST

Does anyone know if the SVN plugin for IntelliJ actually works over ssh now? I tried it a few months ago, and it didn't work. Overall, the plugin didn't seem very well written.

The CVS integration into IntelliJ is the only thing that makes CVS remotely bearable.

This comment is for the good of the syndicate.
SVN? Neh... (none / 1) (#185)
by Surial on Tue Oct 25, 2005 at 11:35:26 PM EST

For all the experience with team programming since the years of yore when CVS was introduced, SVN really isn't all that much to write home about. I guess not updating or changing paradigms too much can be a good thing, but SVN is NOT a superset of CVS, capable of acting just like a CVS server in a clinch.

So one major plus for not going overboard with renewals hasn't even been exploited.

I'm going to skip SVN and go straight for stuff like codeville.

NB: There's good reason to either be backwards compatible or, if an upgrade is neccessary, to go far enough so no new upgrade is neccessary for a considerable number of years. For example, eclipse has a very very good built in CVS system that is very tightly integrated. There is a SVN plugin but it lacks most of those integration features I just talked about. The upside to SVN is not nearly enough for me to consider abandoning almost all of eclipse's integration.
"is a signature" is a signature.

The future: no version control at all (none / 1) (#186)
by Philip Dorrell on Wed Oct 26, 2005 at 03:39:44 AM EST

In my article Disorganized Incremental Software Development, I outline a system for naming code components according to a cryptographic hash of their contents. This eliminates name collisions, rendering source code version control unnecessary, since every source file has only one version. (However version control is still required for the comments, for instance to explain that a function with a name like "a65ib9kjhjdkjj98733012kfkkdj5954gdoku" is actually an implementation of the quicksort algorithm.)

What is Music? Solving a Scientific Mystery
monotone (3.00 / 2) (#205)
by anmo on Wed Oct 26, 2005 at 06:51:17 PM EST

take a look at monotone; no version numbers, just hashes

[ Parent ]
KDE and GCC (none / 0) (#196)
by joib on Wed Oct 26, 2005 at 09:32:01 AM EST

For some reasonably high profile users of svn, there's KDE at least.

And GCC is switching, starting today in fact!

One gripe is that a checked out gcc tree will now take 900 MB instead of 300. But OTOH diff is faster since you don't have to contact the server. And disk is cheap anyway..

Don't forget.... (none / 0) (#230)
by ckaminski on Fri Oct 28, 2005 at 02:43:14 PM EST

Samba, Apache Group and almost all of tigris.org.

Sourceforge hasn't gone yet because they have to plan out 100,000+ migrations, and because there, not everyone will want to use SVN over CVS.

[ Parent ]

13. Omit needless words. (2.00 / 2) (#200)
by bg ex plus alpha on Wed Oct 26, 2005 at 11:51:18 AM EST

Interesting article (none / 0) (#215)
by strlen on Wed Oct 26, 2005 at 11:33:17 PM EST

First, the problem isn't technology, it is how it is used. The number one rule should be:

1. Do not comit broken code (or be shot).

The corollary from this is:

  1. Unit-test
  2. End-to-end test
Number one suggestion implies automation. Number two can be automated in most cases (this is especially true of things like CGI application, where curl and lynx could go a long way; of course this should always be done for CLI applications)

I don't see how locking would work, it seems more like a superficial solution. The real answer is:

1. do cvs update before you do cvs commit

See a conflict with code someone else wrote? Fix it. Get on the internal IRC server (hint: it isn't just for posting links to a flash animation you found funny), communicate to resolve the problem.

The issue with tools like Eclipse or MSVC is that they allow one to easily mess up the infra structure. Automake/autoconf or even regular make are far more manageable when created and edited by hand rather than by a tool. And if anyone claims that their $BLOATED_IDE can do something emacs can't, they're either ignorant or lying. Debbuging inside emacs has been done for least fifteen years  (note: I personally prefer to use vim to edit code and ddd to debug, but that is a matter of taste; emacs is still a far better tool than any IDE).

[T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.

I disagree with your rule#1 (none / 0) (#221)
by eraserewind on Thu Oct 27, 2005 at 08:02:33 AM EST

Well, not disagree so much as feel that it is inevitable that it will be broken by someone, and on a fairly regular basis in any large project. The key is having a way to quickly identify when it happens, and make people responsible for fixing whatever they break. Everyone makes mistakes, but so long as you have a way to recover then it's no big deal. Better a smooth recovery process than a hostile environment where everyone is afraid to make any changes. Of course if you have to wait 8 hours for the build to complete before you find something is broken, then you have a flawed process to begin with, and your rule#1 is likely to find itself invoked in anger repeatedly. This article is worth a read. He seems to have a good system worked out for whatever he is developing.

[ Parent ]
Rule #1. (none / 0) (#231)
by ckaminski on Fri Oct 28, 2005 at 03:32:40 PM EST

The builds in trunk ALWAYS build successfully, and always pass unit/end-to-end testing.  If they do not, they are not committed.

If you merge changes into your branch, and your tests fail, you know it's in YOUR code.

Always apply this condition to rule #1 and there is no problem with determining who caused the issue.  Finding the root cause may be a different story, but the code that breaks is yours.

[ Parent ]

The Real World (none / 0) (#252)
by cburke on Thu Nov 03, 2005 at 08:31:43 AM EST

It's not really that simple.  Capitalizing and bolding "always" doesn't prevent someone from committing code that worked in their environment but not another.  It doesn't stop someone from committing code that passes the unit tests but contains a bug that isn't sensitized until some future change is made.

The project I work on uses automatic testing of checkins.  It does a clean check out and compiles all builds that we care about, and runs our unit tests, and reports pass/fail (with fail messages going to the entire group).  

This methodology is fairly robust.  Running the tests oneself prevents most problems.  Yet the committed version is occasionally broken for reasons I mentioned above.  Environment issues are pretty easy to track down, latent bugs not necessarily so.  Usually the person whose commit failed testing can find the bug, but it can also be several hours of chasing red herrings because in fact they did not cause the issue.

That said, it is certainly fine to attempt to follow rule #1.  Just recognize that it is really more of a wish than a rule, and be prepared for when your wishes don't come true.

[ Parent ]

DO check in broken code (none / 0) (#257)
by reftel on Mon Nov 07, 2005 at 04:19:21 PM EST

First, the problem isn't technology, it is how it is used. The number one rule should be:
  1. Do not comit broken code (or be shot).

WHAT? That's just bizzare. The harder you make it for people to version control things, the more they will work outside the version control. People should check in what they have whenever convenient for them, no matter how broken it is.

They should, of course, never do that on a branch that others see without their consent, but that's a given. With decent tools, branches are free. Use them.

[ Parent ]
Need for personal as well as group version control (none / 0) (#263)
by doom on Sun Mar 05, 2006 at 09:28:24 PM EST

I think the OP has an attitude common in traditional software shops that use CVS, where running a branch is a black art. Myself, I think there's a need for a "personal" version control in addition to the group version control. You should be able to do check-ins every five minutes, if it makes you feel better, without worrying about the state-of-the-build, or cluttering the group's change log (or spamming them with change messages, if they're getting email for every check-in). But checking code into the group repository is a more serious matter, and you do what you can to avoid checking in broken code. This distinction between "personal" and "group" can be done with different branches, or just with different version control systems. If you look in the emacs docs, you'll see they discuss how to switch backends on the fly when you're using the vc.el package. Hypothetically you could use RCS for intermediate check-ins and CVS when you're ready to give something to the group. (I say "hypothetically" because I haven't gotten this trick to work yet, myself.)

[ Parent ]
One more time... (none / 0) (#217)
by Entendre Entendre on Thu Oct 27, 2005 at 02:32:28 AM EST

...without the misguided tangent about commercial versus open-source software:

Interesting things are happening at bazaar-ng.org. It's not ready for prime time yet, but if they follow through to their goals, it'll be pretty cool. (And there's reason to be optimistic - they're funded and they've been self-hosting for a while now.)

Reduce firearm violence: aim carefully.

Another editor that doesn't suck (none / 0) (#240)
by coyotl on Sun Oct 30, 2005 at 10:41:20 AM EST

BBEdit doesn't suck.

Hm... (none / 0) (#241)
by skyknight on Sun Oct 30, 2005 at 10:45:11 AM EST

It refers to itself as a "professional HTML & text editor. I find that somewhat odd. Why do they say HTML and text. It's a weird distinction, sort of like "alcohol and drugs". Is it touting itself as being especially good for editing HTML? Personally, I want an editor with which I can edit anything and everything. I don't want to be in the business of using a different text editor for every job, operating with each one at a mediocre level. For me, Emacs provides a way to edit a wide variety of textual documents with a single tool, allowing me to become highly proficient in its usage.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Don't get hung up on the marketing. (none / 0) (#245)
by mindstrm on Mon Oct 31, 2005 at 05:47:14 PM EST

It's likely that way because a lot of people new to the field think HTML is somehow different and unique.  BBEdit has a bunch of rich features for HTML editing.

Myself, although I have a copy of BBEdit, and use it occasionally, and totally respect it as the king of editors on the mac..

I prefer Ultraedit... it's a damn fine application.

[ Parent ]

Some people say it does (none / 0) (#254)
by qu1j0t3 on Thu Nov 03, 2005 at 01:00:51 PM EST

(Disclaimer: I've used BBEdit probably since v1.0. But I more frequently use vi.) loudthinking.com: It felt so much out of place alongside my Cocoa applications that it along with its immensely bloated features list just left me cold. BBEdit unchallenged reign of high prices and debatable feature set is coming to an end. I can't wait until MacroMates decides its time for release, so everyone can partake in the goodness that is TextMate.

[ Parent ]
It's a misunderstood technology (none / 1) (#244)
by rleyton on Mon Oct 31, 2005 at 06:58:14 AM EST

Excellent article.

I've been frustrated myself by very similar issues in the past, to the extent that after my last contract, I sat down and wrote an essay/article (excuse the plug) "Version Control: A misunderstood technology", where I try to tackle some of the same issues covered here, that I've encountered all-too-frequently as an evangalist for version control in various organisations. It's perhaps a bit more general in that I've found far too many (perhaps as many as 80% in some places) of software 'engineers' are entirely oblivious to basic version control techniques, let alone the benefits of certain approaches.

Anyway, you elequantly cover a number of the topics, and it's a relief to see that there are increasing numbers of like-minded folk out there who do in fact "get it", and are prepared to try and improve others understanding and appreciation.

Good stuff.

Ooooooooooooooh! What does this button do!? - DeeDee, Dexters Lab.
My Website

An important omission (none / 0) (#246)
by GGardner on Tue Nov 01, 2005 at 10:33:10 AM EST

Fear of branching is, as you point out, a common fear for the version-control newbies. A more common fear, is the fear of backing out a change. I've seen a lot of groups that use branches, but have never used a reverse-merge to back out a change. This is as short-sighted as making backups of your filesystem, but never trying to restore from them. If you can't use reverse-merge to back out a change, you aren't getting the full value of version control.

[ Parent ]
While you may have a point... (none / 0) (#247)
by bcRIPster on Tue Nov 01, 2005 at 02:43:32 PM EST

This article didn't entirely help even as informative as it was. In fact, it was such a compelling sell for me to try Subversion as an alternative to CVS or Source Safe, that I went ahead and plunged in.

Of course, there are no RPMs for the latest release... so I'm off the scary forest of tedius Linux installs.

I'm running Fedora Core 2, and I have YUM configured to pull from the Fedora Core project. YUM installed Subversion 1.0.9 as the most recent build, but I wanted to try out the latest version that appeared to be the mature product I was hoping for.

So... going through the documentation, I performed an SVN command against the repository and pulled down the latest build. That wouldn't complile since my system was only at APR 0.9.4... The required APR versions weren't pulled down with the Subversion install, and the command they provided in the Documentation failed to pull down anything. (Yum said 0.9.4 was the most recent!). So, I pulled down the TAR files for the latest APR and unTARred them in the Subversion directory.

Then Subversion succesfully executed the configuration and make commands.

Now when I run the SVN command I'm getting a missing library error.

I've burned 4 hours at work yesterday on this, and over 4 hours at work this morning on it.

Guess what. This sucks. If this were the first time this had happened I would be bummed, but this is so par the course for 50% or more of my Linux experience, dating back to 1996 an my early frustrations at having to manually tweak refresh rates for my monitor to simply be able to bring up a basic GUI.

... I would really just like to uninstall this mess that I've made on my server, but guess what? God knows what was added, what was changed, and where all the files are.

This really sucks. I've just added 240MB of crap to my server and I don't know what I can safetly remove without breaking everything in the process.

[ Parent ]

Use a distro that doesn't suck. (none / 0) (#248)
by skyknight on Wed Nov 02, 2005 at 08:46:57 PM EST

I use Gentoo at home. I hardly ever have problems building packages, and when I do, the problem tends to get fixed in a couple of days, and I just run a sync with the portage tree. What experience I've had administering Red Hat systems has sucked. RPM is garbage. Gentoo's ebuild system is very nice. Usually.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Thanks, that was a constructive reply (sic) (none / 0) (#250)
by bcRIPster on Wed Nov 02, 2005 at 09:35:35 PM EST

Subject is the message!

[ Parent ]
Red Hat is the MS of free Unices. (none / 0) (#251)
by skyknight on Thu Nov 03, 2005 at 06:04:46 AM EST

You probably really do want to be running either Gentoo or some flavor of BSD. Gentoo is really good about having cutting edge packages, but things come out in a constant stream so sometimes reliability can suffer. OpenBSD, on the other hand, has a much longer release cycle, but when stuff does come out is has been thoroughly subjected to integration testing.

In any case, when I started using Gentoo, I was dumbfounded by how easy the package manager, emerge, was to use. It's hardly ever the case that I can't just type "emerge foo" and have package foo install with all of its dependencies resolved automatically for me. I couldn't believe that anybody would put up with the inanity of RPM when such a simple but powerful alternative was available, but hey, I can't believe that anybody who has even a basic level of technical sophistication would use Windows. If you don't even know that a better way exists, it's easy to continue suffering.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Try debian. (none / 0) (#262)
by ChefSalad on Tue Feb 14, 2006 at 08:37:24 PM EST

Some other replyers "Try Gentoo." I say to try Debian. Its not that I don't like Gentoo, in fact I use it every day, and on several systems. It's just that if you're using Fedora Core and you're having problems installing subversion from source, then you probably aren't yet advanced enough to survive an installation of Gentoo. In the end, though, Debian and Gentoo both give you the same, ridiculously awesome feature: single command software installs that not only work but work well and handle dependencies perfectly every time. apt-get on Debian; emerge on gentoo.

I was anonymized for submitting rusty fanfic to the queue in poor taste involving gay sex, aids, and a rusty nail. Let me serve as lesson for all.
[ Parent ]
Thanks. (1.50 / 2) (#249)
by skyknight on Wed Nov 02, 2005 at 08:51:05 PM EST

A solid understanding of version control is indeed a prerequisite for being a serious software engineer. Anyone who claims otherwise is a poseur. Unfortunately, hardly anyone who calls himself a software engineer really is. Most people just barely qualify as programmers, and to use the "engineer" descriptor is downright shameful.

I'll take a look at your article and post another comment. It's a bit too long for me to read at just this moment as I've got to go pick up my dinner.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Nice articel (none / 0) (#258)
by hubb on Mon Nov 28, 2005 at 08:12:02 AM EST

I'm a software eng student, and I enjoyed reading your article. The ending, however, regardless of being in jest or not, is tasteless. I think there's a better way to advocate your preference in development tools rather than telling those who use others to 'kill yourself'.
Life is no way to treat an animal
Well... (none / 0) (#259)
by skyknight on Fri Dec 23, 2005 at 01:22:23 AM EST

I figured that it was such an obvious rehash of an age old Internet flame war that it would be interpreted as the tongue-in-cheek jest that it was. In any case, I'm glad that you liked the article.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
a joke? (none / 0) (#260)
by viza on Tue Feb 07, 2006 at 07:01:01 PM EST

I still use vi for 90% of my day LOL. -Viza

[ Parent ]
Personally, I couldn't imagine... (none / 0) (#261)
by skyknight on Tue Feb 07, 2006 at 08:20:56 PM EST

a world without Emacs.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Toward Saner Version Control | 263 comments (160 topical, 103 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!