Hacker News Reader

Comment by mmastrac | Hacker News Reader

Good thing we're using a shared Samba drive and editing files directly without locks!

We have post-its with file names on a wall in the office. You take one down if you edit the file, and put it back up when you're done. Easy.

Though I wish I was entirely kidding. ~12 years ago or so we did that if one of two parallel development teams had to modify a message of the network protocol to avoid incompatibilities and merge problems.

Mind you, these were SVN merges. I can't even verbalize my feelings about SVN merges but by a mixture of laughing and groaning in pain, like if you stubbed your toe in a painful, but entirely funny way.

Keeping it when tech can't keep up is genuinely a good hack for any kind of engineering. Physical lock out tag out on industrial machines for instance. Passing paper notes/wooden blocks in air traffic control towers to see who's responsible for what even if computers go down.

What is this eternal meme about merges in svn being harder than in other tools? Git used literally the same merge algorithm, even if that has changed a bit since then, and merge conflicts are not something a tool can't just magically make disappear. If you want concurrent edits (the c in cvs), conflicts come in the same package. Various algortihms can supply their own dose of magic, but they're more similar than different (minus a few special cases such as rerere in git).

My interpretation within that company: You know this new idea of "If it's painful, do it more"? People in that company didn't do that in the SVN days or earlier, because merges were painful. Thus, merges filled a sprint if they had to be done. This made sense if you came from CSV or nothing, tbh.

Git in turn made branches easier, causing merges to be more prevalent and developers overall learned to merge more, merge more often.

That doesn't make any sense to me. Why would you merge more often if it takes less time to create a new branch?

What types of merges are we talking about? Surely it must be where you merge in changes from a main branch to your local branch, which in the case of long-lived branches will be the more common merge. Creating new branches isn't even part of that workflow.

We used a whiteboard. I'm not joking either. This was about 14 years ago. FTP FTW

Project_v2_final3 is looking good, but remember to grab the new actionscript files out of Project_v2_final4 as well.

Also the foo_bar method from v1 worked better so pull that back in

You joke, but when I was doing my start-up we made good money on the side from monitoring websites to detect when the designers had pushed regressions to the live site. We would keep track of change requests that were filed and resolved, then scripts would monitor the sites to see if any earlier changes had been backed out. (Getting the designers to use version control was considered to be in the "too hard" bucket. This was back in the mid 2000s.)

This is how to collect low to mid 5 figures a year doing bug bounties too

Its all about the regressions, not finding anything novel

If this isn't cosplay I'd be glad to know how you do so.

So glad we never bothered to migrate from Visual Source Safe

That's a single point of failure. If you email code changes around and use an email client that copies everything offline, then the history of your code base is distributed across all of your developers' laptops.

Make sure everyone has caching disabled, for maximum effect

Still better than CVS then /s

Reply on news.ycombinator.com