231–240 of 287 posts
Just bite the bullet and convert the repo from SVN to Git?
Guessing the primary issue is the time it takes to convert the repo, maybe a job to do over the holidays when most people are off?
Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information…
This is a great comment, except for the last line, which is extreme hyperbole.
Unequivocally yes. I switched companies (FANG) to my family software company and the company had been using Microsoft Visual SourceSafe. The company was only casually using it, as one computer was used to compile customer executables (and fix compile-time linker errors) and was often times never checked into VSS. Needless to say, no one on the SWE side knew if any code actually worked or when anyone did anything. Par…
> I switched companies (FANG) to my family software company > After I joined and learned about the horrors of VSS, I switched our company immediately to git (there was some initial resistance) Be careful with changes in these situations. "Some hotshot coming from FAANG and telling us how we should do things" doesn't always play well.
1) We found a nasty heisenbug that crashed with a useless unrelated stack trace, but only if you didn't have a debugger attached, and only if you held open the windows 8 "charm bar" open for more than 10 seconds, and only on the main menu screen. After wasting a couple weeks trying to root cause it with logic, I eventually resorted to brute force bisecting perforce history by hand - and then the changes within the changelist to blame, as it was a large one. This let me figure out it was a bug in a seemingly completely unrelated, closed source system API, that we were calling to check internet connectivity. I had to write a standalone repro case to prove to myself it was the cause, it seemed so nonsensical. I wrote a workaround. This bug was only a few months old though, because QA was able to catch it early enough. The bug likely would've eventually gone unfixed without perforce history.
2) I went to upgrade a 3rd party dependency that we checked in, that hadn't been upgraded in years - maybe even a decade - for bugfixes and such. Except we'd made changes to said 3rd party dependency, so I needed to seperate out and understand our changes to the baseline SDK so I could decide if I should re-apply them to the updated SDK (in some cases yes! I was able to drop others.) We had a web interface to an archived SVN repository containing the commits before our years-old Perforce transition - and before my employment there - which I used to help me grok it all. I might have reached as far back as a decade in this case - very low frequency of commits to that part of the code, however, so "a decade" might have meant "the past 10 or 20 commits", if that. I had to reach out to IT to even get credentials to see said history. Helped turn a nervwracking upgrade into a tame one.
3) We decided to port an archived, years-old project to a new platform. Just seeing the last change made to sanity check if the weird logic I'm seeing might be a "new" bug or not means looking at years old history. This has actually happened to me a couple of times.
Earlier quoted context omitted.
I love reading through revision history but it's so, so easy to mess up given people and time. We have a long history spread across several different (generations of) SCMs. I see each of the following quite often: Most recent revisions (version A, code comments date code to the 90s): - 2011-02-03: Migrate to git - 2008-01-12: Migrate to SVN - ~Fin~ Most recent revisions (version B): - 2018-12-12: Split out into own f…
I once worked on a codebase where almost every mystery in the code could be traced back to a commit "Moving TIM one level down", and no further.
"How are we almost level 100 now? We're going to need an exemption soon!"
"We'd better go move around some orphaned, 20 year old C code to avoid triggering this well-meaning organizational policy!"
I was sure you and I must have worked at the same company. Alas, TIM isn't named TIM here though.
Earlier quoted context omitted.
How's the AAA industry nowadays? I got out awhile ago (though HoN never really counted as AAA) but it was a fun ride at the time. Is work life balance a bit better now, or does everyone still push themselves pretty hard?
It's both better and worse than its ever been. There's an awareness and discussion about "sustainable" development practices, but a large portion of our workforce had to leave for stress reasons last year, on a project that is saying "sustainable development" the loudest.. so while it feels like lip service, at least there's an awareness at some level. (also, gamers are more entitled than ever, so we're always runnin…
- is it common for AAA companies to claim ownership over all ip you create, even outside work? (My last job did this)
- How would one find part time or short term contract work in the games industry?
Granted, the context didn't really change what the fix needed to be, but it did provide a useful moment of reflection on the ways in which software can break through subtle changes over time that stack up, and it helped to know that the section of code that broke was indeed originally intended to work the way it did (and not that it was a bug from the very beginning).
If migrating all old commits is such a challenge (it shouldn't be), then a workaround could be to keep your SVN online but in read only mode. If your git blame shows "Initial migration commit" you just move over to blame in the old svn.
Frequently. Just this evening I was looking in the HN repository for the last version of the code that pg wrote, to remind myself how he used to do something. One of my favorite tricks is to make a file out of all the changes in the history: git log -p > bigass and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in the…
> and then grep through the file (edit: which I like to do in Emacs—hence the file)
Since you already have Emacs, I would suggest you do M-& git log -p RET instead. No need to round-trip the data through a file.
If migrating all old commits is such a challenge (it shouldn't be), then a workaround could be to keep your SVN online but in read only mode. If your git blame shows "Initial migration commit" you just move over to blame in the old svn.
Every bug ends up blamed on the whitespace guy who goes around correcting tabs to spaces.