7 ms·

FreeBSD src repository is transitioning from Subversion to Git this weekend

212 points by cnst 6y ago

mikece 6y ago
I suspect interest in FreeBSD will rise with the demise of CentOS. What are the DevOps best practices for working with and deploying to jails instead of Docker?
- ggm 6y ago
  Absent a good equivalent of Dockerfile, and compose features, I think this is doomed. (Longterm freebsd user btw)
  - hda111 6y ago
    What’s wrong with BastilleBSD?
    - inetknght 6y ago
      I imagine the only thing wrong with it is that it's not nearly as well known as Docker.
      - ggm 6y ago
        Yes, mostly this. I think its targeting a different deployment model.
        tpetry 6y ago
        I am not using it but the features sound fantastic, like a complete network for every jail without complex docker network interface solutions. Why dont they do a freebsd container runtime based on the jail semantics? They sound much more effective than the linux ones. Ok, the problem would be on how to run linux executables on freebsd.
        ggm 6y ago
        Ok, the problem would be on how to run linux executables on freebsd. That problem is mostly solved. Has been for years except for marginal sysctl() calls unlikely in datacenter usage of Linux.
    - ggm 6y ago
      Nothing, except it doesn't look to be doing additive composition on top of images and it doesn't look familiar if you were targeting pods in a k8s style deployment. As a thing in itself? Its fine. If you have 5+ years investment in docker, the missing, parts here are going to hurt. Mainly, what's missing is helpful evidence of transition. E.g. I have a docker image i got from git which works as a one-shot execution chain to run xml2rfc and I got a version for cramdown which worked mostly the same way to do rfc/drafts from markdown. Where's the BastilleBSD equivalent? How do I translate a Dockerfile to a Bastille script?
- tofaz 6y ago
  There is a great simple framework that can ease a lot the deployment and management of Jails called BastilleBSD. You can install it with pkg install bastille. https://bastillebsd.org/ https://bastillebsd.org/
- UI_at_80x24 6y ago
  They are vastly different creatures as you know, but in my experience on long-lived-but-must-keep-running services, fat-jails are a MUST. OS package mismatches will bite you in the ass years down the road if you try to maintain thin-jails. I manage alot of sites that Management refuses to invest any dev-time to upgrade old Python2.7 infrastructure. Having fat-Jails allows me to keep everything else upgraded. pf is a fantastic firewall, but the syntax in OpenBSD is different then in FreeBSD. VNET is worth it's weight in gold. Each jails has it's own network stack. That let's you avoid funky localhost workarounds. iocage is a great framework for jails management (but it isn't necessary) you can do everything from jail.conf. Personally I prefer it for it's ZFS integration.
  - rsync 6y ago
    Hmm ... I was about to respond and say the opposite :) My (personal) unbound jail has 95 files in it. The reason it has so many files is because it is simultaneously my 'nsd' jail. Which is to say, I actually point two different 'jail' commands at the same directory - each with a different IP and command line: /usr/sbin/jail /jails/dns ns1 1.2.3.4 /nsd/nsd -c /nsd/nsd.conf /usr/sbin/jail /jails/dns dns 1.2.3.5 /unbound/unbound -c /unbound/unbound.conf So /jails/dns is a holder for two different dns servers and they run, jailed, from the same root. It's a little unorthodox but in this case I find it to be elegant.
    - toast0 6y ago
      I agree. I would run jails with very few files. A static executable, a config file, a log file, and some pipes maybe. Don't need anything else, don't want anything else (log file could be avoided with syslog, perhaps)
      - rsync 6y ago
        Bonus points: chflag schg the exe and config files such that they cannot be altered ... or better yet, make it a zfs filesystem and mount it read-only ...
    - UI_at_80x24 6y ago
- cesarb 6y ago
  > I suspect interest in FreeBSD will rise with the demise of CentOS. Indeed, the first thing I thought when seeing this post was "I wonder how long the support for each FreeBSD release is". Looking at Wikipedia (https://en.wikipedia.org/wiki/FreeBSD#Version_history https://en.wikipedia.org/wiki/FreeBSD#Version_history), it seems to be around 5 years. Still no match for the 10 year support CentOS users expected; IMO, 5 years is too short when installing out of cycle (for instance, since the current stable 12.x was released two years ago, if I installed it today on a new computer I'd have only 3 years of support left).
  - thijsvandien 6y ago
    This is much less of an issue with FreeBSD because the changes between releases are relatively small. Some systems out there had 20 years worth of upgrades, from v4 all the way to v12. I wouldn't like to try that on Linux.
    - emidln 6y ago
      You could probably get pretty close with Red Hat Linux 7.2 or 7.3 to 8 to 9 to Fedora Core 1 and on. There might be a break somewhere that the upgrade doesn't work, but nothing sticks out in my mind. Anaconda is a seriously impressive install/upgrade system.
  - gspr 6y ago
    > 5 years If indeed 5 years suffices, Debian LTS may also be a candidate.
MaxBarraclough 6y ago
I'm a little surprised they seem to be going with GitHub, I figured the FreeBSD folks would rather host it themselves. edit Or perhaps not? This exists: https://git.freebsd.org/ https://git.freebsd.org/
- emersion 6y ago
  IIRC the plan is to have a proper self-hosted Git repo, and mirror it on GitHub.
- sudobash1 6y ago
  The link in the article is to discussion & documentation, not the destination for the code. In the big picture file[1] it says: > We'll self-host the git repo and manage the first layer of mirrors ourselves. We'll publish the repository to github, gitlab and other places that are useful for our developers, users and contributors. 1: https://github.com/bsdimp/freebsd-git-docs/blob/main/big-picture.md https://github.com/bsdimp/freebsd-git-docs/blob/main/big-pic...
  - MaxBarraclough 6y ago
    Thanks I'd missed that.
- howeyc 6y ago
  Based on the migration docs, looks like they are hosting themselves. GitHub/GitLab will have mirrors.
cnst 6y ago
Almost hard to believe it's finally happening! Couldn't we have gone with Git all along, without Subversion as an intermediary step for about a decade? Anyhow, per https://wiki.freebsd.org/git https://wiki.freebsd.org/git, looks like GitHub/GitLab will have the new stuff on Tuesday, 2020-12-22T10:00Z; this'll likely require manual actions if you're exporting Git from GitHub. Personally, I'll probably be switching over to exporting directly from FreeBSD.org at that time, because GitHub still doesn't even support IPv6.
- sudobash1 6y ago
  My source is Wikipedia, but FreeBSD is so much older than git. Git is only a decade and a half old (from 2005).
  - V-eHGsd_ 6y ago
    https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committ... freebsd switched to subversion in 2008. I would guess that git was just too new in 2008.
    - andoriyu 6y ago
      It wasn't just new, CVS to subversion was nearly drop-in change. It didn't require change in process - FreeBSD project could have kept its Cathedral style process. Git is too different from SVN and CVS. The real problem was - someone had to work on the switch itself. There is so much tooling that had to be adapted to new version control. Everyone talked, but no one sent any patches. The same reason it is taking so long to switch from Subversion to Git. I can't find it right now, but I've watched a video that explained CVS -> SVN timeline for FreeBSD. Here is "short" version of it: https://lists.freebsd.org/pipermail/freebsd-current/2008-June/086023.html https://lists.freebsd.org/pipermail/freebsd-current/2008-Jun...
    - cnst 6y ago
      FWIIW, Matthew Dillon has converted DragonFly BSD from CVS directly into Git back in 2008, or, more specifically, on 2008-11-26: https://leaf.dragonflybsd.org/mailarchive/commits/2008-11/msg00122.html https://leaf.dragonflybsd.org/mailarchive/commits/2008-11/ms... It would appear that FreeBSD has switched the src repo from CVS into SVN on 2008-05-31. Sure, Git surely must have improved since 2008, but did it really miss any really important features that have since been implemented back then, or is it just a matter of a much wider acceptance than anything else? It looks like $FreeBSD$ tags are now deprecated, because they aren't supported in Git; I recall these tags have always been the biggest blocker in any VCS considerations for both FreeBSD and NetBSD. TBH, I got the impression that they've never been properly supported by Subversion, either -- you had to install a FreeBSD-specific version of SVN for the tag expansion to work "properly". I still think SVN is the worst out of all the VCS -- it has all the drawbacks of a centralised Git without many of the benefits, plus none of the benefits of CVS. For example, I wanted to have a local mirror on the history of the tree, which is absurdly easy to do with CVS with rsync -- you can even selectively ignore certain parts of the tree like --exclude "…src/contrib/???…/" --exclude "…src/gnu/…/…" (how do type a star symbol on HN?), but mirroring SVN was so complicated and inflexible that I had simply given up after it had used up way more space than the prior rsync mirror of CVS had ever required, and still wasn't even done. I then decided to entirely bypass SVN by directly switching to an "unofficial" git repo once the export from SVN back to CVS was completely deprecated and deleted at one point.
ogogmad 6y ago
How did they do the conversion?
- craftkiller 6y ago
  Looks like this is the repo for the scripts: https://github.com/freebsd/git_conv https://github.com/freebsd/git_conv which seem to be invoking this svn2git program (which is also copied into the freebsd/git_conv repo): https://github.com/svn-all-fast-export/svn2git https://github.com/svn-all-fast-export/svn2git
Maledictus 6y ago
This makes me sad. Subversion is such an elegant and simple versioning system. I really wish something would come along that does for git what subversion did for CVS.
- srgpqt 6y ago
  Well, mercurial is kinda like a svn-flavored git
  - yjftsjthsd-h 6y ago
    NetBSD was looking at mercurial last time I looked (with parallel implementations in mercurial and git), so hopefully they'll use it at least.
    - mekster 6y ago
      Does mercurial have something like git svn to bridge between so that others may use git protocol? I'm getting tied of git and disappointed no one wants to get off of it instead more are using it.
      - craftkiller 6y ago
        https://www.mercurial-scm.org/wiki/HgGit https://www.mercurial-scm.org/wiki/HgGit
  - simias 6y ago
    I agree, I still think that git vs mercurial was the VHS vs betamax of VCSs. Git was better for the kernel, but mercurial was better for basically everything else. Saner defaults, much more user friendly, better CLI and GUI, better docs etc... Unfortunately as far as I'm concerned it's over. Git has won. It's just way too popular now, other DCVSs can't compete.
    - gmueckl 6y ago
      Don't fool yourself. It's only over if YOU think it's over. The Mercurial ecosystem is actually getting better and better.
enriquto 6y ago
Great. Slowly approaching the features of more mature systems like DragonflyBSD.
- ben_bai 6y ago
  You don't know what you are talking about.
- yjftsjthsd-h 6y ago
  Okay, I'll bite... what features does dragonfly have that freebsd lacks?
  - enriquto 6y ago
    The src repository is on git. That's the only think I was talking about, and obviously in jest ;)
  - moonchild 6y ago
    Supposedly better SMP support (this may no longer be true; benchmarks are several years old; but it may very well be). HAMMER.
    - nix23 6y ago
      >HAMMER No ZFS
jasoneckert 6y ago
The reluctance towards moving to git in the FreeBSD community actually provided the central theme in the book "git commit murder": https://mwl.io/archives/2913 https://mwl.io/archives/2913
- cperciva 6y ago
  Hey, that book is about SkyBSD, not FreeBSD. (Also, it's Warren Lash who gets murdered, not Warner Losh...)
jimbob45 6y ago
Our company will never transition from SVN to Git because the transition tools fail on our ancient SVN repo. Learn from us: switch now because switching later may not be an option.
- deleted 6y ago
  [deleted]
- alkonaut 6y ago
  I migrated a 100k (20 years, 100Gb history) revision 20Gb workingcopy svn repo with full history and it was pretty painful. But in the end, so long as you can check out any revision (i.e. the repo is functional) then migration should also work, as should updating the repo format to the latest svn repo format. I assume the upgrade to a recent svn format is what's blocking? Even so, worst case it should theoretically be possible to do a looped checkout+commit from svn to git. Metadata such as commit dates can be rewritten later if needed.
  - Arnavion 6y ago
    You could also just keep the SVN repo around for its commit history and start a new git repo with the trunk imported without history. Sure you'll have to switch back and forth between the two repos for history, but over time it'll become less and less necessary. Microsoft has done this for many long-lived repos; Windows and SQL Server are the two famous examples, with multiple such transitions.
    - christophilus 6y ago
      Those weren’t using SVN, though, I don’t think. I can’t remember the name of the version control system they used, but it was some custom license of a proprietary system. Clear-case, maybe? Anyway, it was a nuisance, and I imagine the move to git was both a money saver and ultimately (once all of the migration pain and missing capabilities had been addressed) a nicer dev experience.
      - 6y ago

212 points by cnst 6y ago

I suspect interest in FreeBSD will rise with the demise of CentOS. What are the DevOps best practices for working with and deploying to jails instead of Docker?

ggm 6y ago
Absent a good equivalent of Dockerfile, and compose features, I think this is doomed. (Longterm freebsd user btw)
- hda111 6y ago
  What’s wrong with BastilleBSD?
  - inetknght 6y ago
    I imagine the only thing wrong with it is that it's not nearly as well known as Docker.
    - ggm 6y ago
      Yes, mostly this. I think its targeting a different deployment model.
      - tpetry 6y ago
        I am not using it but the features sound fantastic, like a complete network for every jail without complex docker network interface solutions. Why dont they do a freebsd container runtime based on the jail semantics? They sound much more effective than the linux ones. Ok, the problem would be on how to run linux executables on freebsd.
        ggm 6y ago
        Ok, the problem would be on how to run linux executables on freebsd. That problem is mostly solved. Has been for years except for marginal sysctl() calls unlikely in datacenter usage of Linux.
  - ggm 6y ago
    Nothing, except it doesn't look to be doing additive composition on top of images and it doesn't look familiar if you were targeting pods in a k8s style deployment. As a thing in itself? Its fine. If you have 5+ years investment in docker, the missing, parts here are going to hurt. Mainly, what's missing is helpful evidence of transition. E.g. I have a docker image i got from git which works as a one-shot execution chain to run xml2rfc and I got a version for cramdown which worked mostly the same way to do rfc/drafts from markdown. Where's the BastilleBSD equivalent? How do I translate a Dockerfile to a Bastille script?
tofaz 6y ago
There is a great simple framework that can ease a lot the deployment and management of Jails called BastilleBSD. You can install it with pkg install bastille. https://bastillebsd.org/ https://bastillebsd.org/
UI_at_80x24 6y ago
They are vastly different creatures as you know, but in my experience on long-lived-but-must-keep-running services, fat-jails are a MUST. OS package mismatches will bite you in the ass years down the road if you try to maintain thin-jails. I manage alot of sites that Management refuses to invest any dev-time to upgrade old Python2.7 infrastructure. Having fat-Jails allows me to keep everything else upgraded. pf is a fantastic firewall, but the syntax in OpenBSD is different then in FreeBSD. VNET is worth it's weight in gold. Each jails has it's own network stack. That let's you avoid funky localhost workarounds. iocage is a great framework for jails management (but it isn't necessary) you can do everything from jail.conf. Personally I prefer it for it's ZFS integration.
- rsync 6y ago
  Hmm ... I was about to respond and say the opposite :) My (personal) unbound jail has 95 files in it. The reason it has so many files is because it is simultaneously my 'nsd' jail. Which is to say, I actually point two different 'jail' commands at the same directory - each with a different IP and command line: /usr/sbin/jail /jails/dns ns1 1.2.3.4 /nsd/nsd -c /nsd/nsd.conf /usr/sbin/jail /jails/dns dns 1.2.3.5 /unbound/unbound -c /unbound/unbound.conf So /jails/dns is a holder for two different dns servers and they run, jailed, from the same root. It's a little unorthodox but in this case I find it to be elegant.
  - toast0 6y ago
    I agree. I would run jails with very few files. A static executable, a config file, a log file, and some pipes maybe. Don't need anything else, don't want anything else (log file could be avoided with syslog, perhaps)
    - rsync 6y ago
      Bonus points: chflag schg the exe and config files such that they cannot be altered ... or better yet, make it a zfs filesystem and mount it read-only ...
  - UI_at_80x24 6y ago
cesarb 6y ago
> I suspect interest in FreeBSD will rise with the demise of CentOS. Indeed, the first thing I thought when seeing this post was "I wonder how long the support for each FreeBSD release is". Looking at Wikipedia (https://en.wikipedia.org/wiki/FreeBSD#Version_history https://en.wikipedia.org/wiki/FreeBSD#Version_history), it seems to be around 5 years. Still no match for the 10 year support CentOS users expected; IMO, 5 years is too short when installing out of cycle (for instance, since the current stable 12.x was released two years ago, if I installed it today on a new computer I'd have only 3 years of support left).
- thijsvandien 6y ago
  This is much less of an issue with FreeBSD because the changes between releases are relatively small. Some systems out there had 20 years worth of upgrades, from v4 all the way to v12. I wouldn't like to try that on Linux.
  - emidln 6y ago
    You could probably get pretty close with Red Hat Linux 7.2 or 7.3 to 8 to 9 to Fedora Core 1 and on. There might be a break somewhere that the upgrade doesn't work, but nothing sticks out in my mind. Anaconda is a seriously impressive install/upgrade system.
- gspr 6y ago
  > 5 years If indeed 5 years suffices, Debian LTS may also be a candidate.

MaxBarraclough 6y ago

I'm a little surprised they seem to be going with GitHub, I figured the FreeBSD folks would rather host it themselves. edit Or perhaps not? This exists: https://git.freebsd.org/ https://git.freebsd.org/

emersion 6y ago
IIRC the plan is to have a proper self-hosted Git repo, and mirror it on GitHub.
sudobash1 6y ago
The link in the article is to discussion & documentation, not the destination for the code. In the big picture file[1] it says: > We'll self-host the git repo and manage the first layer of mirrors ourselves. We'll publish the repository to github, gitlab and other places that are useful for our developers, users and contributors. 1: https://github.com/bsdimp/freebsd-git-docs/blob/main/big-picture.md https://github.com/bsdimp/freebsd-git-docs/blob/main/big-pic...
- MaxBarraclough 6y ago
  Thanks I'd missed that.
howeyc 6y ago
Based on the migration docs, looks like they are hosting themselves. GitHub/GitLab will have mirrors.

cnst 6y ago

Almost hard to believe it's finally happening! Couldn't we have gone with Git all along, without Subversion as an intermediary step for about a decade? Anyhow, per https://wiki.freebsd.org/git https://wiki.freebsd.org/git, looks like GitHub/GitLab will have the new stuff on Tuesday, 2020-12-22T10:00Z; this'll likely require manual actions if you're exporting Git from GitHub. Personally, I'll probably be switching over to exporting directly from FreeBSD.org at that time, because GitHub still doesn't even support IPv6.

sudobash1 6y ago
My source is Wikipedia, but FreeBSD is so much older than git. Git is only a decade and a half old (from 2005).
- V-eHGsd_ 6y ago
  https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committ... freebsd switched to subversion in 2008. I would guess that git was just too new in 2008.
  - andoriyu 6y ago
    It wasn't just new, CVS to subversion was nearly drop-in change. It didn't require change in process - FreeBSD project could have kept its Cathedral style process. Git is too different from SVN and CVS. The real problem was - someone had to work on the switch itself. There is so much tooling that had to be adapted to new version control. Everyone talked, but no one sent any patches. The same reason it is taking so long to switch from Subversion to Git. I can't find it right now, but I've watched a video that explained CVS -> SVN timeline for FreeBSD. Here is "short" version of it: https://lists.freebsd.org/pipermail/freebsd-current/2008-June/086023.html https://lists.freebsd.org/pipermail/freebsd-current/2008-Jun...
  - cnst 6y ago
    FWIIW, Matthew Dillon has converted DragonFly BSD from CVS directly into Git back in 2008, or, more specifically, on 2008-11-26: https://leaf.dragonflybsd.org/mailarchive/commits/2008-11/msg00122.html https://leaf.dragonflybsd.org/mailarchive/commits/2008-11/ms... It would appear that FreeBSD has switched the src repo from CVS into SVN on 2008-05-31. Sure, Git surely must have improved since 2008, but did it really miss any really important features that have since been implemented back then, or is it just a matter of a much wider acceptance than anything else? It looks like $FreeBSD$ tags are now deprecated, because they aren't supported in Git; I recall these tags have always been the biggest blocker in any VCS considerations for both FreeBSD and NetBSD. TBH, I got the impression that they've never been properly supported by Subversion, either -- you had to install a FreeBSD-specific version of SVN for the tag expansion to work "properly". I still think SVN is the worst out of all the VCS -- it has all the drawbacks of a centralised Git without many of the benefits, plus none of the benefits of CVS. For example, I wanted to have a local mirror on the history of the tree, which is absurdly easy to do with CVS with rsync -- you can even selectively ignore certain parts of the tree like --exclude "…src/contrib/???…/" --exclude "…src/gnu/…/…" (how do type a star symbol on HN?), but mirroring SVN was so complicated and inflexible that I had simply given up after it had used up way more space than the prior rsync mirror of CVS had ever required, and still wasn't even done. I then decided to entirely bypass SVN by directly switching to an "unofficial" git repo once the export from SVN back to CVS was completely deprecated and deleted at one point.

ogogmad 6y ago

How did they do the conversion?

craftkiller 6y ago
Looks like this is the repo for the scripts: https://github.com/freebsd/git_conv https://github.com/freebsd/git_conv which seem to be invoking this svn2git program (which is also copied into the freebsd/git_conv repo): https://github.com/svn-all-fast-export/svn2git https://github.com/svn-all-fast-export/svn2git

Maledictus 6y ago

This makes me sad. Subversion is such an elegant and simple versioning system. I really wish something would come along that does for git what subversion did for CVS.

srgpqt 6y ago
Well, mercurial is kinda like a svn-flavored git
- yjftsjthsd-h 6y ago
  NetBSD was looking at mercurial last time I looked (with parallel implementations in mercurial and git), so hopefully they'll use it at least.
  - mekster 6y ago
    Does mercurial have something like git svn to bridge between so that others may use git protocol? I'm getting tied of git and disappointed no one wants to get off of it instead more are using it.
    - craftkiller 6y ago
      https://www.mercurial-scm.org/wiki/HgGit https://www.mercurial-scm.org/wiki/HgGit
- simias 6y ago
  I agree, I still think that git vs mercurial was the VHS vs betamax of VCSs. Git was better for the kernel, but mercurial was better for basically everything else. Saner defaults, much more user friendly, better CLI and GUI, better docs etc... Unfortunately as far as I'm concerned it's over. Git has won. It's just way too popular now, other DCVSs can't compete.
  - gmueckl 6y ago
    Don't fool yourself. It's only over if YOU think it's over. The Mercurial ecosystem is actually getting better and better.

enriquto 6y ago

Great. Slowly approaching the features of more mature systems like DragonflyBSD.

ben_bai 6y ago
You don't know what you are talking about.
yjftsjthsd-h 6y ago
Okay, I'll bite... what features does dragonfly have that freebsd lacks?
- enriquto 6y ago
  The src repository is on git. That's the only think I was talking about, and obviously in jest ;)
- moonchild 6y ago
  Supposedly better SMP support (this may no longer be true; benchmarks are several years old; but it may very well be). HAMMER.
  - nix23 6y ago
    >HAMMER No ZFS

jasoneckert 6y ago

The reluctance towards moving to git in the FreeBSD community actually provided the central theme in the book "git commit murder": https://mwl.io/archives/2913 https://mwl.io/archives/2913

cperciva 6y ago
Hey, that book is about SkyBSD, not FreeBSD. (Also, it's Warren Lash who gets murdered, not Warner Losh...)

jimbob45 6y ago

Our company will never transition from SVN to Git because the transition tools fail on our ancient SVN repo. Learn from us: switch now because switching later may not be an option.

deleted 6y ago
[deleted]
alkonaut 6y ago
I migrated a 100k (20 years, 100Gb history) revision 20Gb workingcopy svn repo with full history and it was pretty painful. But in the end, so long as you can check out any revision (i.e. the repo is functional) then migration should also work, as should updating the repo format to the latest svn repo format. I assume the upgrade to a recent svn format is what's blocking? Even so, worst case it should theoretically be possible to do a looped checkout+commit from svn to git. Metadata such as commit dates can be rewritten later if needed.
- Arnavion 6y ago
  You could also just keep the SVN repo around for its commit history and start a new git repo with the trunk imported without history. Sure you'll have to switch back and forth between the two repos for history, but over time it'll become less and less necessary. Microsoft has done this for many long-lived repos; Windows and SQL Server are the two famous examples, with multiple such transitions.
  - christophilus 6y ago
    Those weren’t using SVN, though, I don’t think. I can’t remember the name of the version control system they used, but it was some custom license of a proprietary system. Clear-case, maybe? Anyway, it was a nuisance, and I imagine the move to git was both a money saver and ultimately (once all of the migration pain and missing capabilities had been addressed) a nicer dev experience.
    - 6y ago