> Your bogus rationalizations sound like you haven't held a software job working with other developers in twenty-five years, if ever.

Video codec people are kind of weird as developers. Consider ffmpeg and libav. They're certainly competent, just weird.

Interesting point, and I happen to have worked with the internals of ffmpeg on the job, so I understand. (I gave it a plugin architecture, supporting dynamically loaded AVParser and AVCodec objects, supporting hardware acceleration.)

I dunno. Statements like in the link make me question if someone is actually competent.

someone's grasp of best practices in vcs is in no way an indicator of their programming or cs abilities

But it could still be an indicator of competence.

To reason about software, it's a useful cognitive tool to be able to simplify gigantic systems down to interfaces and black boxes.

Carrying that notion of isolating components too far, such that you don't consider human cooperation as part of the system? It happens often, but we also often distinguish this with statements about EQ versus IQ rather than summing it all up as competence.

(Yes, you used the word indicator. I'm speaking to the community more than you specifically.)

Think you're correct - this has been his gig for 20 years, before that apple and sun for ~5 years, before that, academia.

Either that or he's using VSS and is mortally embarrassed.

I remember the infrequent releases and not-very-collaborative development from the GNU Project once upon a time -- you get a new release with an announcement on an announce list and availability on the FTP site, a couple of times a year or sometimes less often. And that's about it, because it's the maintainer's responsibility to maintain the code. (Of course, you can contribute patches which the maintainer can accept or reject, and you can fork the program if you want. And some of the projects did have public discussion lists, but not all of them, and not at first.)

This is still the way that NetHack development works. :-)

It feels like something of an anachronism now, but it highlights the existence of a distinction between free and open source code (you can exercise certain freedoms with respect to any release) and collaborative development (you can potentially help create the release without having a formal relationship with the developers). I know Google has also been criticized around AOSP for being less transparent and collaborative than the present-day norm. Maybe they should defend themselves by comparing themselves to the NetHack Dev Team!

I have a source code repository for the code I write on my computer to track changes, and then I upload tar.xz's of the project for each "release". I can't see much benefit in opening a source code repository; if someone finds a bug, he can e-mail me a patch or even notify me about it.

Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code.

Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs.

Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once.

If I was going to use a public repository, I think I'd end up using CVS.

If it's a personal project, it's largely a matter of taste, I think. I did tarball-upload style myself before.

I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests).

Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.

> if someone finds a bug, he can e-mail me a patch or even notify me about it.

A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes."

Users can run "blame" to find out which commit touched what line of any file.

Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage.

> then I upload tar.xz's of the project for each "release".

All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag:

  $ git tag frumly-widgets-2.3
  $ git push --tags

Done! Users can now download frumly-widgets-2.3.tar.gz straight out of the web front end.

> If I was going to use a public repository, I think I'd end up using CVS.

Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.

You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about.

Result? Nice discussion. Opportunity for folks to learn something new.

And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.

Just look at the website itself... It's straight out of 1995, is it any wonder his views on source control are from 1990?

Git bisect is only available for git and (at least) subversion has no comparable command, so unless you are willing to force everybody to use git (and that may not be bad) you aren't guaranteed to get anything useful out of it.

Heck git allows you to edit the history pretty widely, right (I have only limited experience with git myself)? So in this case he could maintain a separate upstream repository which only contains the releases, with all the intermediate commits sanitized.

I know it's svn is just an example but:

http://git-scm.com/docs/git-svn

The svn plugin to git let's have a git repo that is a clone /client of an svn repo. Very handy if you have an svn upstream but need to work offline.

Git, Mercurial, Darcs, Monotone, and Baazar all have a built-in bisect and for svn there are well used external scripts (like svn-bisect).

git bisect automates the process, but the underlying technique should work with any VCS. and i've scripted it up in SVN several times to good effect

Git has bisect because Torvalds and co. did the same thing outside of version control using kernel tarballs.

"Hmm, it still worked in 2.2.13, but not in 2.2.37. Let's try 2.2.25."

I've been in situations where I was desperate enough to do it by hand. 20+ builds and manual tests later, I found a really nasty bug in some 3rd party code that manifested with the most bizarre repro that had no obvious connection even in hindsight, and symptoms involving cleanly exit(3)ing out of the program from a totally unrelated bit of code.