the bulk of their sales is, in fact, hardware sales. there is a strong case to be made that such developments wouldn't land people in squarely linux-as-the-only-OS-on-the-device territory either, but rather dual boot ie those users also participate in the walled garden on the mac os side. we've seen this before in the intel mac era.
SVN in SVN for sure, it's a well made product. The market just didn't like it's architecture/UX that doctates what features available.
CVS is not much different from copying files around, so would not be surprised if they copied the files around to mimic what CVS does. CVS revolutionized how we think of code versioning, so it's main contribution is to the processes, not the architecture/features.
My first software job, I was a junior person, and every Friday, we would have The Merge, where we'd merge every SVN branch into trunk. We always spoke of it like it was this dreadful proper noun, like Voldemort or something.
The junior engineers were the ones doing this, and generally my entire day would be spent fixing merge conflicts. Usually they were easy to resolve, but occasionally I'd hit one that would take me a very long time (it didn't help that I was still pretty inexperienced and consequently these things were just sort of inherently harder for me). I just assumed that this was the way that the world was until I found `git-svn`.
`git-svn` made a task that often took an entire day take something like 45 minutes, usually much less. It was like a light shining down from heaven; I absolutely hated doing The Merge, and this just made it mostly a solved problem.
After that job, I sort of drew a soft line in the sand that I will not work with SVN again, because at that point I knew that merging could be less terrible. I wasn't necessarily married to git in particular, but I knew that whatever the hell it was that SVN was doing, I didn't like it.
Is it really any different than forcing everyone to `git-rebase` their work to the latest (shifting) `main` on Fridays? Then the tool does not matter.
As usually happened (and happens today with git) -- everyone just tries to get their changes merged sooner, so it's the others' person problem to resolve merge conflicts. And that's good for velocity. Why doing it on Fridays only?
By the time git became well known, sure, SVN fell from favour very quickly for good reason. But it had a few years in the sun. Not nearly as long as Git has had at this point.
There were also many holdouts in places that didn't need complex merges.
Having a fixed merge cadence strikes me as both utter madness and totally inflicted nightmare, though. If you're going to merge on a fixed cadence rather than when things are ready, you almost might as well have people push straight to trunk.
reply