Hacker News Reader

Comment by roenxi | Hacker News Reader

Normally lauding a "sub-optimal" tech means the optimal tech isn't a fit for the problem space or the cost of adoption is higher than the benefits. Something like Tarn doing everything in C/C++ which is arguably good and arguably bad but works. It is unclear that switching languages would be a net win or loss.

In the case of not using a VCS system "sub-optimal" means he's making his own life difficult for no gain. It is difficult to see that it is anything other than a mistake - a 20 year old project with 700k lines of code is going to benefit from version control. The only saving grace is that Dwarf Fortress development predates git so at least there is a good excuse for how it happened this way, but it is still a mistake.

We all make mistakes though, so the world will continue to turn if Tarn sticks to it.

View on HN

I've noticed that people tend to have varying differences in their mental map of organization. If you view a codebase as largely monolithic with only a few states such as previous/backup, current, and future/editing, the addition of version control may not help workflow. Editing is always a rolling-release model, be it backwards or forwards (at least that's what I interpret from "there is kind of an active molten core that I have a much better working knowledge of" in the article. If version control were introduced, you would now be tasked to actively divert workflow to the versioning software, such as when reverting commits, etc. You don't create a repo for trivial objects, such as a simple shell script you write for your personal desktop, so it's easy to see this applied to scale, especially with a single-person codebase like DF. For the script example, a file will typically have undo/revert history in an editor, which itself is a limited form of version control. So there obviously has to be some form of version control used by the author other than file copying, albeit not as explicit as git. I think it's unfair to call it a mistake unless you're directly affected. In the 20 years of (solo?) development of DF, do you not suppose a rational person would adopt versioning were a lack thereof impacting them noticeably? So obviously it's a non-issue as far as scope of the codebase goes.

I understand your example, but as a counterpoint: I do keep simple scripts in version control, too.

But the real simple stuff usually starts out in my misc scripts folder. But that's more for filesystem organisation, not because creating a git repo has any (mental) overhead.

> In the 20 years of (solo?) development of DF, do you not suppose a rational person would adopt versioning were a lack thereof impacting them noticeably?

If they never got around to learning about version control, it's totally imaginable that they are sort-of rational, and that version control would have improved their lives.

> version control would have improved their lives

Not sure. I use git at work, but I would never use it for my solo projects. It just doesn't add anything I need, but it takes mental effort to manage it.

I use it for my solo projects as well, but my commit messages (and history manageent in general) is much better when I'm writing for other people.

If nothing else to see and learn from your own history. Imagine a rich 20 year history of commits. Even if it was all the most basic system with just branches and commits and merges. I am still a source control simpleton after 20 years, but having a few branches using git is rather trivial.

Well there must be 20 years worth of backups. I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files. Bonus points for detecting branches.

> I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files.

'course there is. While Linus didn't bother, there are people who rebuilt the Linux history from the tarballs, and you can `graft` the historical sequence and the "real" one to get something of a continuous history from 0.01 to today.

It's a lot of work though, old archives often contains partial garbage data (many of the rebuilt linux history incorrectly attribute various historical commits to 2007)

Yes, PostgreSQL did this when they switched from CVS to git. They used that as an oportunity to prrpend the history woth the contents of some ancient tarballs that they had.

Assuming there is a folder for each release, all you would have to do is commit the first release then each subsequent release.

So after the first release, for every release delete all the files in the folder except the .git folder and copy the next set of source files in and commit.

Doesn't account for branches, but seems like this would work and could be done quickly with some shell script.

I did exactly that at work, when I inherited maintainership of a legacy internal software program, which until then has been developed with the same "version control" approach as DF - a folder/zipfile per release or per feature branch.

As a bonus, it is something that has to run on three different operating systems, and the source code for each has been kept separately, and synced manually every now and then.

Granted, it was only like a dozen or so releases and not 20 years worth of development like DF, but that's just a matter of scale, not of principle. :)

I managed code in version control long before Git, and before DF existed in 2002 we had decent and sometimes great tools (ClearCase?). Still, I personally do not care how other people work. Different strokes for different folks, etc.

ClearCase was expensive, unless you pirated it.

As far as other opensource go to solutions, CVS and SVN, branching in them was nontrivial. Many folks preferred zipped folders to using CVS/SVN.

Linus Torvalds famously preferred tarballs over CVS.

For further discussion, keep in mind that thanks to competition from git etc, modern svn is substantially more bearable than it used to be before distributed version control systems became popular.

What is so hard about creating a branch in CVS and SVN?

My first SCM was RCS and have used most of them since then.

Even with all this experience I rather just redo my local devenv than take a PhD degree in git implementation to fix repo state.

You don't remember when your CVS admin would send out the email announcing the repo would be frozen for the next 48 hours so a branch could be created for the golden master? I don't know why it was such an onerous task but the disruption creating a branch would cause was significant given you would only commit every few weeks when all your changes were ready. Compared to modern VCSes it was like having no VCS at all.

But SVN had cheap and quick branching.

No, because creating a CVS branch was relatively easy.

https://www.astro.princeton.edu/~rhl/cvs-branches.html

Looks like you had a lousy IT.

You know what happened when you did that one simple command that every sysadmin hates? It copies all of the thousands of files containing all the millions of lines of production code from spinning rust-coated glass to spinning rust-coated glass on system that run at hundreds of megahertz. If anyone accidentally checks in a change between when the copy starts and when it ends, the entire source history going back years gets horribly and irretrievably corrupted and you need to spend a couple of days restoring everything from backup, which is inevitably rust-coated mylar tape to rust-coated spinning glass disks, rebuilding indexes as you go. That is assuming the restore from backup actually works, which is rarely if ever tested and you know full well even if it is tested that's the day you experience not one but multiple disk failures probably because of all the intense activity. Meanwhile you lost your slot at the manufacturing facility in Taiwan because your golden master wasn't delivered in the brief window required and they have already retooled the line for another customer. Maybe you can recover from the financial loss, or maybe your sysadmin just takes the reasonable precaution of freezing access to the CVS repo for the days the branch takes to create, and schedules it over a weekend to minimize downtime.

You have to wonder why, twenty five years ago, the sysadmin didn't just synch the entire network to the cloud through his iPhone. That, of course, would just show how none of was is your lived experience.

Really lousy IT.

Maybe at one point ClearCase could have been considered state of the art, but that ship has long sailed. I used it professionally from 2004-2013, and it was awful. Branching was slow. Well, everything was slow. It was way too easy to miss new (view private) files. Non trivial merges were atrocious. We were begging to migrate to svn...

Reply on news.ycombinator.com