My previous employer still uses svn. It created so much headaches and frustration due to unproductivity because e.g. someone pushed a bug without testing and you unknowingly downloaded it. No way to easily reverse of course. It was my first job after University and taught me that CRUD b2b Java enterprise jobs are to avoid at all costs in the future. For what it's worth though, I had some very funny-sad stories to tell when I interviewed to get out of there after just 6 months. Never tought a versioning system could burn me out. Git is standard for very obvious reasons.
It sounds like you didn't know svn, because what you describe is the most basic feature of any version control system - being able to revert to any of the previously submitted versions is basically the reason VCSs exist. In addition pretty much every svn GUI frontend should have provide a single click way to check out a local copy of a previous version that you can commit if you want.
Svn has some warts (shelving feels sooo half baked despite having like 3 different ways for that) but at least reverting to an older state isn't one of them.
I prefer Git, I've invested a lot in learning it, and have done presos and training for it over the years. But I cut my teeth on CVS, and Subversion was a significant improvement over CVS.
Not that I expect anybody to maintain historical perspective. Linus Torvalds famous 2007 rant at Google shitting all over Subversion and its developers set the tone for a long tradition of anti-Subversion anti-history. Never mind "learning from what's gone before", it's like there was only backwards progress until the tool du jour was suddenly invented ex nihilo.
Revert to the previous version. Push as new version. Fixed? SVN was used widely and for years, prior to git. I remember the biggest problem being expensive (full copy) branching.
Creating branches is not expensive in SVN, because it’s copy-on-write (server-side). Maybe you mean switching the local working copy to a different branch?
Not sure what you mean. Copy-on-write means that no actual copy is made initially. Branching is therefore almost instant in SVN and only requires minimal storage space. Only when you modify a file within the branch (or the original) does that specific file get copied (or rather, the diff of the modification gets stored).
What is slow in SVN is switching to the branch client-side, because branches are always created server-side and you still need to synch the whole contents of the branch from server to client when switching (which works similar to a regular `svn update`).
I'm not sure what you mean either. I don't care what SVN does now, only what it did when companies abandoned it en-masse around SVN v1.6, since that's the context of my comments.
SVN branches were always cheap copies, right from the original version of SVN.
"svn cp http://.../trunkhttp://.../branches/foo" may not be the most concise command to type, but all it does is create a new item "foo" in a new revision, which references a previous item "trunk" in a previous revision. How many files/directories are under that doesn't affect how long the operation takes.
What I described is what SVN always did. Cheap copies due to COW was always a selling point for SVN. My point is whatever was slow for you wasn't due to COW.
It's one of my interview questions when applying for a job. I say something along the lines: "I know this is a ridiculous question, but do you 1) use version control and 2) what version control do you use" and then explain I have to ask these questions becz of obvious reasons.
I had a job in the late 90's at a newly formed subsidiary of a multi-billion dollar corporation. The product was cobbled together from various third party software they licensed or acquired outright, and we were customizing. You would think they'd have set up version control to at least keep track of what came from where. Nope. Here I was, a 22 year old kid, teaching people about CVS. SVN wasn't quite out yet.
If you've only worked in very small, mom-and-pop style companies, you might run into this. I knew small companies (under 30) that ran without version control for over a decade. These were PHP shops that did most of their development on a dedicated server, with people editing files remotely over FTP (or SFTP if you were lucky.)
There's a blog post from the early 00s called The Joel Test for judging a software team. Using source control is actually the first question. Sounds like you reinvented it :)
Don't apologize for your questions! You're interviewing the company just as much as they're interviewing you and poor attitude in responding to such questions is a red flag IMO.
That said, if you're worried about how your questions are perceived, a little rewording can suss this out and give you more context. I like to ask:
What does your software development process look like? Tell me about how you manage, test, and deploy your product.
You can rephrase a lot of questions in a similar manner to get what you want and leave room for the interviewer to expand (or justify!) their responses.
I didn't mention what I was subtly after, which was the facial expression after asking that question.
Usually it's sigh and a nod of the head (as if they are remembering THAT company). That's a good sign for me.
There is a mutual recognition that we've both worked in some terrible companies and learnt how NOT to do some things. This generally means (and some good followup questions) that they have CI/CD,a PR review process, some ticket tracking, agile/kanban etc.
I'm generally not worried about how my questions are perceived as that's a red flag for me. If they have a problem with that, then most likely not a good place (culturally) I want to work.
Also: wear the nicest thing you'd wear for work to the interview, even if that's just a t-shirt (because you are a slob and proud of it). If you don't get the job as a result of your clothes, you didn't want that job.
For anyone looking for it, it's not as intuitive as git. In svn, you reverse-merge the commits from the current branch's history you want to revert:
svn merge -c-123 . # single commit, the second "-" is "do the merge backwards"
svn merge -r123:122 . # Multiple commits in reverse order, "the change going from 123 to 122"
Git makes branching and merging easier, and the whole history is available locally. You can just ignore those buggy commits and base your work on an older version; when someone eventually fixes the bug, you can merge the bug and its fix into your changes, to become up-to-date (with the possibility of conflicts, but nothing is completely free ;) ).
I once took a job at a place that had migrated from git to perforce because it was the "corporate standard." Some departments worked with large binary assets (videos, sound files) where I understand it made more sense. We were developing web apps. This was almost a decade ago now, and working with it felt tedious. I also made it about 6 months.
