To me, the arrival of Git and Mercurial was a godsend, not because it was radically different than what I was used to, but because it finally meant that I had a sufficiently advanced general-purpose DVCS that I at last could cleanse the ground with the blood of my enemies obliterate the use of Subversion, CVS, that thingie that Microsoft made before TFS, and anything else that might cross my path, and replace them with Mercurial (or, in a truly desperate situation, Git) goodness. Hell, I built a whole product centralized around making DVCSes easy and simple to use, and then went on the lecture circuit explaining how to best use them in your workflow.
This man has the creds, now listen up as he hits the high points of working with a distributed source control management tool.
Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years […] I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. But for the rest of us, I am going to assert that this is not the use case you need to optimize for when choosing a VCS.
I rolled my eyes the first time another developer told me that Git was so cool because he had the whole repo, history and all, for our one of projects. I could care less about the whole repo. I want the trunk because I’m building something that I want to ship as soon as fucking possible. I don’t care about some bullshit somebody changed six months ago.
Take blobs (a.k.a. binary assets). Blobs are a part of most programs. You need images. You need audio. You need 3D meshes. You need to bundle a ton of fonts, because Android has like three of them, none of which happen to be Wingdings. These are large, opaque files that, while not code, are nevertheless an integral part of your program, and need to be versioned alongside the code if you want to have a meaningful representation of what it takes to build your program at any given point.
That’s fine for a centralized system. You only have one copy at any give point, so the amount of disk space you need is basically the size of the current (or target) version of the repository—not the whole thing. We don’t really need to care about how the history is stored.
With a DVCS, though, we have a problem. You do have the whole history at any given point, which in turn means you need to have every version of every blob. But because blobs are usually compressed already, they usually don’t compress or diff well at all, and because they tend to be large, this means that your repository can bloat to really huge sizes really fast.
Again with the obese repo sizes. The first Git project I worked on, Github told me that my .sql file was too large when I went to push. Being new to Git, it took me the better part of an hour to get it out of the repository. That particular project is almost a gig — for one website.
I see this workflow done for the tiniest of tiny projects on the grounds that “it makes things easier”. Yet I watch OpenBSD, an entire freaking operating system, get by just fine with CVS—CVS—and patch bombs.
At work I’m constantly being bombarded with “latest buzzword” that we need to incorporate into our development models and work flows. “Everybody else is moving to this, we need to do the same” bullshit. “We need to switch our MySQL deployments to MongoDB so they’ll scale” — shit like that pretty much every day.
If it’s not going to help us ship this fucking project tomorrow, if it doesn’t make my life easier — to hell with it. Stay the fuck outta my way fanboi, I’ve got billable, production work to do.
Anyways… For everything source control, I’m just fine with Subversion.
#devhell #worknews
jimi hindrance experience
you need to kick him in his nuts.
Reply
Post
visual:
if you were to saw off his head…
Reply
Post