There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS.
Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git.
I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.
Yes, I think what a lot of people forget is that git was designed specifically with the Linux kernel in mind. Linus wrote it to the workflow of his project without much regard for what other projects do. That's fine; there's nothing wrong with that at all. It just means that it's not suitable for every project, and that's a good thing: different types of projects should use tools that are actually designed for them.
It also explains why git has such a strong learning curve: it was written for kernel hackers. The only people who were expected to use it are the kind of people who are used to delving deep into the nitty gritty. It's why I'm kinda disappointed GitHub became the dominant public source code host, because Mercurial is IMO much better at actually being penetrable to new users. I think people who are mostly familiar with SVN would be far, far more at home with Mercurial than git.
Mercurial? Works everywhere much more simply, even ties into .NET with VisualHG and gives a better version/branch management than TFS. And doesn't mismanage disk space like Git.
Mercurial + BitBucket is the cleanest, fastest way I have right now for adding devs to new projects. I avoid Git because so few people (ESPECIALLY those who have only used Git) understand source control well enough not to make a mess of it.
That's really one of the core problems of using git and why it's not for everyone. If you want a tool to do your job then git won't make you happy. Using the core tools and learning how it works _inside_ is the only way to make it work efficiently.
If you want/need a bike (something easy like svn), use a bike. If you want/need to use an air plane (git) you need to learn how to fly and that costs a lot of time. Putting something on the plane to make it look like a bike (a tool that may or may not enable all of git but probably not) won't suffice in either case.
Maybe your team isn't a bunch of road-warriors but networks still drop packets, servers get overloaded and many people work remotely using imperfect VPNs & ISPs. It's really easy to forget how much time that used to waste but switching to Git meant that we no longer had daily chatter when any of those flared up & people just got on with life.
That said, I'd love to see some focus on tooling which improves the painful parts you mentioned. I'd love to share binary data in Git and it's possible but painful. Similarly, the main selling point for Git on internal projects is the massive performance and usability wins over most of the competitors but there's no reason why that must be the case other than inertia on the part of the other options.
The point was simply that “low” is not the same as “does not apply” and that matters when it's something which prevents someone from doing their job. Even when I worked at 100% on-site projects, I used git-svn so I could make local commits and ignore locking mishaps.
Don't get me wrong, however, I'm totally in agreement for having better tools for supporting the local, centralized workflow. The other reason I used git-svn was because merging was much more reliable and I could rebase changes to squash commits before sharing them with others. All three of those features should work well in any serious version control system regardless of whether it's centralized.
(1) If this doesn't apply to your office network get a better network. Now.
Bollocks. I've had two machine failures in eight years, versus at least 20 network failures. Sure, maybe the network admins at five different companies I've worked for all just happen to be a bunch of muppets, but I highly doubt it.
That's your privilege. I don't. The only time I remember the network going down was after a complete air conditioning failure in the server room (a highly unlikely event in itself, but not IMPOSSIBLE) which forced a complete shutdown of IT services. And even then people could still work. Sure, not as well as usual but working was possible. The last time a machine failed was .. oh right. Yesterday.
Also, get better machines. The last time a machine failed at this all-macbook shop was several months ago.
In either case, you will lose unpublished work in the event of a catastrophic local drive failure.
Only in the case of a centralized system, you will also be unable to work unless the entire network path and remote server is available. This will almost never be a question of data loss but it means that you will be unable to perform version control operations until it's resolved.
Plenty of people work via VPN. Not just people that have remote jobs, but people that just work from home one or two days per week.
Why must I be part of a team? Why can't I just be hacking randomly and syncing my history with my personal server as I feel like it.
Sure, go, do. Just don't pretend that there are no teams and no other people that have different use cases.
> I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.
No. The premise is "a system is conceivable that has gits upsides and less of its downsides" and look - facebook is even building it.
As to what Facebook's building, meh. Anyone can try to build a better-in-every-way-for-every-application VCS, but look to TFA for a list of just some of the failed attempts to produce better version control mousetraps. It's more likely that they'll produce something that will be handy for niche uses than something that will be a clear win over git for everyone else.
Sure, there are. I've worked on them. I've had networking not work, servers fail, diffs take forever because of an overloaded server. Honestly, at this point, I can't conceive of working in a centralized VCS anymore, so unless you make a salient point about what can be done with one that can't be done with a DVCS it's all opinion vs opinion.
It's not only "for local commits", although being able to have local branches without polluting a public namespace is a huge win. It's also about _speed_ when you're doing VCS operations. Linus Torvalds actually made the case really well in his talk: https://www.youtube.com/watch?v=4XpnKHJAok8
> There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS.
That's a question that's completely orthogonal to whether or not you use a DVCS. How is a "traditional" VCS going to help you when you can check out the code locally and smuggle it out on a flash drive?
In my company, we use git and there are access restrictions as to who can access and commit to our branches.
> Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git.
..and that's not the use case for git. Linus has been very clear about _what_ git is optimized for, performance wise.
That doesn't mean that DVCSes in general are useless for storing large assets, but that the most popular implementation is. Also, I'm not really sure what traditional VCS you're referring to, that makes it easy to version VM images and remain storage efficient?
I have probably run git init in a directory at least once a month to have full tracking capability without the expense of setting up a "server". It says something that the author assumes that a DVCS can only exists if it has a central server and that your local copy is nothing but the "offline" copy. I have also run projects where the github repo was just a copy and the version on my box was the official repo. I also run expensive (cpu/time) scripts that walk over the projects history, something the server admin would never let me do. And then we get into the realm of very expensive hooks that run on my desktop and not on the "server". And lastly even in an always connected world if your server is in Australia you can't change the speed of light, hitting it from Germany will always be a long "slow" trip.
Having the full repository at your disposal without being tied to some other authoritative repository provides a lot of flexibility and enables capabilities that are just not possible otherwise. Some features could easily be included in non-dvcs systems (such as local hooks), but I do not know if we would have seen their success without dvcs systems providing the means for exploration.
And I love that if I need it on another machine it's just "git clone ssh://..." instead of having to setup a server.
I think the big thing with DVCSes is that you can pretend you have a client-server model with a handful of directories on your local machine. At one point at my present job I replayed a bunch of SVN history through Hg so that I could by-hand divide the work that had been done into a few named branches; this helped me to figure out where things had "gone wrong" in the project. It was really effective to just have a day of SVN update, hg diff, copy files to ../branch_name, commit to hg, rinse, repeat. What I really needed was indeed the "killer feature" that he's saying -- sane branching and merging -- but the fact that it was all easily contained in my filesystem was a nice plus.
[1] http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf
[2] http://darcs.net/Internals/CacheSystem#lazy-repositories-and...
In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.
There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits.
Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase).
Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.
When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about.
Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries.
However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.
Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.
But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.)
With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)
I never said that perforce would perform in any way better, but I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. Try pushing your changes via email to your CI server. Fully decentralized would be beautiful, but I seriously don't see many teams that use git (or any other system) in that manner. Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.
> I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around.
I agree. The first time I read your argument, I interpreted it as a reason to not use git itself, but I think we're on the same page.
> Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.
What else can be done? I don't really want to push changes to my co-workers individually, I want a place to push changes that any co-worker can then pull from — do I not? Toward this goal, certainly I could create n servers, and make pushing redundant over those n servers, have then do consensus to agree on HEAD, etc., but that seems to me to be what I'm paying GitHub to do.
OTOH Perforce had some serious downsides like
* immature eclipse plugin (would crash eclipse more
than once a week, forcing a full reset every.single.time)
* no Netbeans plugin (back then)
* the whole idea of having to decide in advance, -while in
the office or otherwise connected, which files you
needed to modify and therefore "check out" -
* which brings me to the next problem: by default only one
person can work at a file at the same time.
Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo.
I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.
The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that.
I can choose not to run proprietary software without having to not use the web.
Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.
I've worked on a project where the git repository was man gigabytes - because at some point someone decided to put some binary files in the repository, which periodically got updated - now years on the repository's about 10GB, and you can't really delete the stuff clogging it up without rewriting history from years prior and making the 200 devs life hell.
Importantly, you do need all that history, because there are commits from the same time that are relevant.
I agree that git is weak for binaries, but the only binaries I need to keep in it are a few images and installer - nothing that has many versions, nothing that causes me problems. Similarly, a lot of open source software is mostly made up of code, not blobs.
As for distributed work, even when I'm the only developer on a project, it helps not to have to worry about a central server, especially if I'm on-site. It's also hugely faster than SVN ever was.
Better to abandon the ultimately doomed monolithic repo scheme and tool your build and deployment systems to expect a multi-repo ecosystem. Then allow your teams to create their own repos on the fly, one for each individual project if they please. Once you reach that point, there is little reason to not use a more sensible VCS like hg or git.
So basically, you're de facto the field tech example he gave, out in the virtual wilderness of iffy internet.
Not entire world is a goddamn Sillicon Valley. Internet is not electricity, and won't be for a while - free and reliable WiFi ain't everywhere; sometimes you work where you're not allowed to connect to a network, sometimes your ISP decides to fuck up the link for an hour for no reason whatsoever, the other day you work at a venue with office-grade Internet (i.e. slow as hell). And then you might want to hack during commute. Data plans are expensive, not every place on Earth has LTE connection (or any form of reasonable data connection for that matter) - and I don't mean wilderness, I mean the highway between two big cities. And try to tether your laptop to your phone, and then suddenly something decides it's time to download 2GB of software updates and boom, there goes your plan.
Above all that, what happened with the concept of owning the data? I want my stuff available off-line, because it's mine, period. I want to run arbitrary code I write on it, and hell, I sometimes want to open the data in text editor and edit by hand. Moreover, doing constant round-trips around the world to do things that you should be able to do locally is kind of stupid.
EDIT:
And don't tell me about YAGNI and stuff. Version control is infrastructure, and the iron rule of infrastructure is - you use what you have; the more you have, the more you use. If you give me a feature, I'll adapt my workflow to use it, even though I was fine without it before. Cutting down on infrastructure reduces the amount of things people will create with it.
So, in other words, like someone working away from home base...like someone...in the field. I suppose I wasn't clear. I had hoped my use of "virtual wilderness" implied a different domain for "field" that is not necessarily a physical location.
>Internet is not electricity
And there was a time where electricity wasn't ubiquitous either (and it still isn't depending where you are). Such places, then and now, could be reasonably described as being relatively in the field.
>and I don't mean wilderness, I mean the highway between two big cities.
That could definitely fall under working in the field, especially compared to an office.
>Above all that, what happened with the concept of owning the data?
Choose whatever VCS you like for whatever reasons you want; it doesn't matter to me. I'm merely pointing out that I think the author covered that base. You may not be underwater in a submarine, but if you're on the road on your laptop trying to scrounge for LTE or zipping from firewalled office to firewalled office, you may as well be virtually underwater with respect to the Internet.
Edit: All you have to do it jot down the idea if your worried you'll forget about it. You don't have to hand write out all the code that would be silly. I find having a small notebook with me is pretty handy.
http://shop.moleskine.com/FileLibrary/4be794eb3e094e59ac8a8f...
AKA, translated for the git people, "you can work without the internet, you just don't issue pull requests (or pull for that matter)".
Where I work now we still use CVS, and frankly it works fine (even with large binaries checked in). I ran git-cvs for a while, and had a dozen different branches for all the separate features I was working on.
Then I found I was spending a metric crapload of time messing with the version control rather than writing code. CVS may be basic, but in a way that is a plus. It strongly encourages you not to have 20 different features being worked on at the same time, then merging this piece here to that piece there. No, its simple: Work on one thing in your working directory, commit it to the head, pull everyone's changes, go work on the next thing. Repeat.
Eventually I kicked my git-cvs to the curb for plain old CVS. Gives me more focus.
Now I can waste the time I spent on stack overflow (learning how to fix my git screwups) posting here...
No, I fell in love with it because it was distributed and I could work without an Internet connection, which aren't prevalent everywhere, and even in my house, in a large city, can be iffy. By work I mean things like blame, bisect, log, &c not just committing.
> Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times.
Well lucky him for only being able to code when he has a nice connection, not all of us do.
Also, I like the distributed aspect as well. I like not having to give people commit access to my repo for them to have a proper dev env and then they can send me a patch or a PR and we can incorporate their changes. How would they be able to make any commits or anything otherwise without access to my repository?