Abandon your DVCS and return to sanity
bitquabit.com
bitquabit.com
Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky.
Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily.
Other objections to this article:
* Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this)
* The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal.
I could go on, but the article seems to be griping about UX issues. Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.
And for a third, it opens options which are not available without that. Annotating or bisecting with server round-trips every time is not really an option.
That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage".
> The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap.
Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them.
> Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily.
That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.
> Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.
I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.
Why are you asking?
Nexus is pretty good, but if the language you are using isn't integrated well with gradle/maven you can always just use a shared drive fed by jenkins builds.
I could fix the tooling, but alas, I have other yaks to shave. It's an imperfect world.
If you could version the file in git, you would have to check in the new version of the file, so it's not like you're adding a step to have to update (e.g.) a symlink.
Here's where I start to have problems with contemporary development culture. You mentioned using Nexus, Gradle, Maven and Jenkins where the guy just want to keep some binaries along with the source code they're generated from.
We're complicating things beyond reason nowadays.
That said--and this is without knowing the exact build and tooling environment, so I may well be giving advice inappropriate to the situation at hand!--the second part of that "keep some binaries along with the source files they're generated from" is kind of an antipattern.
If it takes too long to generate them from source, each time erry time, they need to fix that issue--least of all because slow builds mean slow testing, and slow testing means no testing.
That's why I spent two days earlier this year moving a 30-minute build down to a 2.5 minute build.
* install all the required instruments for the ritual rain dance
* teach the whole team how to do the ritual rain dance
* support the people that break an arm or a leg doing the ritual rain dance
There are some better solutions to what we're currently doing, but there's so many yaks to shave and so few razors.
Subversion handles this gracefully because you don't download all of the repository's history to your machine. It's a trade-off that you're talking about here. Most people are ok with losing the ability to check in 500MB files in order to gain the decentralization of having a full copy of the repo (and not needing to query the server just to view history).
OP is arguing that these (having to use Nexus, Gradle, Maven, and Jenkins just to keep some binaries along with the source code they're generated from) are workarounds to limitations in git that ideally would not be there (and don't neccesarily have to be there, and aren't there in all VCS's), and the OP mentions that instead git fans want to claim "No, that's just the way git SHOULD work, you SHOULD need to go use an 'artifact repo' in addition to git to keep a few binaries with your source code" instead.
I tend to agree with the OP.
There isn't always a way to dumb things down to the level that people would like. It would be so much easier to get to work if I could fly in a straight line between work and home, but I don't complain that the world doesn't accommodate me.
Put your build tools in a repo. It should be easy to set up a new developer with a complete build system by getting it from the a repo. Now use make or anything that can check dependencies so those things are not regenerated unless they need to be. Always check in a freshly generated file along with its source.
In some cases the tooling of one developer can even conflict with the one of another, one requires python 2.7 to be in your PATH while the other requires 3.3, etc.
I fully agree that it should be easy to set up but the reality is different, especially when you deal with legacy, rely on third party libraries or build open source projects from source.
/src/foo.c /src/foo.o
So essentially, without large binaries in source control we'd lose testing.
git-annex is a pretty good solution for this: https://git-annex.branchable.com/
> That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.
I'm not convinced that it is a strawman– I'm not an uber-developer, but I've had to do it reasonably often. A common case is that the originator loses interest, and you still need to do maintenance on it. I'd rather my go-to choice of a version control system support that notion rather than learn a different tool to deal with this case.
> I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.
Sure, there is an additional level of abstraction, but to argue that it's insurmountable seems rather pessimistic. Most technologies that we take for granted now required multiple decades to get to a consumer-friendly state. This is perhaps a philosophical difference that only time will answer.
Then again maybe I'm a bit psycho-rigid on build management :)
This tends to happen especially in shops that migrate off process-heavy monsters like clearcase and MKS. These tools do a lot more than just version control, and no open source version control system by itself matches what users of these systems expect. You have to throw at least an issue tracker and a good build tool into the mix as well.
Because of "we'll just add a submodule and we don't need a build system and it's only a single one and we'll replace that with a proper build tooling as soon as we have time". And then it's only a second one and suddenly submodules pop up like mushrooms after a light summer rain. It requires planning and forethought, just like a lot of things that should be an obvious huge benefit, but planning and forethought are in short supply in this industry.
And in that cause you can scp your repo somewhere and change your origin and move on.
Also, do people really rely on 3rd party services for their deployed code? I've used github as a repo and colab tool at companies, but we still deployed from repos owned by the company.
> I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.
I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo.
Also, do people really rely on 3rd party services for their deployed code?
Not to mention that in case of an office Internet outage, you can just mesh together those repos and continue working. Knowing that gives me some peace of mind.
It's a valid tradeoff to make, but still something I'd keep in mind.
A successful business is built upon so much more than whatever code is in your repo.
Any competitors are probably more likely to look at the code and ignore it over their own home-grown solution than to adopt it wholesale...and if they can beat you with your own code, they would've beaten you without it, because they probably run a much better business game.
Trade secrets are like the stupidest reason ever to hobble your developers.
If your developers are deploying into production directly from their laptops, you have a problem.
I could also imagine designers placing their assets in the repository without needing to deal with git or even seeing the source code that lives side-by-side. That totally used to work with SVN I'd totally like it if the repository contained the PSD sources for all the assets/mockups that are relevant for a given version of the source, but alas, you can't check out the source without getting the PSDs, even if you're not interested in them. Heck, SVN even allowed exposing the repo as webdav which you could mount as a networked folder, so people could access the last revision just as if it were a SMB drive.
git is a huge step forward in some regards, but we also lost quite a couple of good things along the way.
> If your developers are deploying into production directly from their laptops, you have a problem.
I never said they do.
As for the configuration being in the same repo as the code--again, why? That tells me that you aren't packaging releases, or if you are, your documentation is less useful as a reference than your code.
These are antipatterns, again, and "fixing" your VCS isn't going to help in the long run.
The assets for game development likely are bigger than the assets in web development but we never had major issues with binaries. Things also improved much in later SVN versions (in the beginning the client was way to stupid and tried to diff binaries which obviously could not work)
> As for the configuration being in the same repo as the code--again, why?
Why not? I don't have that right now, but I'd like to have it. Because I could compare the state of the code and the state of the configuration with the state of the code easily at any time at any commit. I could use bisect to figure out at which point things started failing. Helps when you're trying to figure out when config and code started drifting apart. I can use google's repo tool or submodules or stitch together the config repo and the code repo by matching up dates or tagged versions, but that's all a hack. It's maybe the best hack currently available, but I still think there's room for improvement.
> That tells me that you aren't packaging releases, or if you are, your documentation is less useful as a reference than your code.
I can't imagine how you reach that conclusion. You could not be further from reality. Just because I'd consider it nice if I could have a single version identifier in a single repo that matches up both, config and code I'm not rolling that in a package? And how does that relate to my documentation?
Of course they do. But those repos should live on an internal repo server, and on the production systems themselves.
Copying production authentication credentials to a non-production machine should be a firing offence.
> And it would not be of value if we could version the configuration along in the same repository as the code to which it belongs? So it's easier to track?
Hell no. Code without configuration is like a gun without bullets: it's an interesting piece of work, but that's it (I'm not a huge believer in intellectual property, you can tell). But configuration is the keys to the kingdom. If a cracker has your app's code, he might be able to figure out some flaws in your protocols or your implementation, but if a cracker has your database passwords, your hostnames and IP addresses, your firewall configuration, your bastion hosts—then you're dead.
Currently there's code in one repo and configuration in another. Both repos are on the same internal repo server. Both repos are accessible to multiple persons - some can access the code only (developers) and some can access the configuration repo only and some can access both repos (admin). A build process tags both repositories and builds an artifact that gets deployed.
How is that situation superior in terms of security over:
Code and configuration live side by side in the same repository that supports access controls. The repository is hosted on an internal repo server. The parts that are code are accessible to developers only and admins can access both parts. A build process tags the repository and builds an artifact that gets deployed.
The only point I could see is that with two repositories it's harder to mess up the authentication, but I doubt that's true. In both scenarios we have people with access to the configuration and those people will in a lot of organization have a copy on their laptop that they carry around. That's how most people use version control. In both setups it would be possible to only ever handle the sensitive data on a remote system, but that's a property of the workflow and not a property of the VCS used. I seriously don't see the issue with a shared repo - if it supports access controls.
You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works. In SVN you don't even need to expose the full history, you can grant access to the last revision only.
> Just as in most VCSes, you can set up a git server to only allow checkout of specific branches
In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads.
I'm not sure what you're getting at. What difference is there (not that you would allow checkouts on unencrypted laptops anyway)?
> In SVN you don't even need to expose the full history, you can grant access to the last revision only.
> In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads.
These restrictions may be useful in some cases, but I would wager that they are far more seldom than some of the advantages of git (like being able to work offline).
A checkout from SVN/CVS only contains the last version. Files that were deleted in an earlier version are only on the server. A clone of a DVCS contains all versions and all files that ever were in the repo (unless you use BFG or git-filter-branch, but people tend to forget that). So a clone can contain secrets that people are not aware of, such as accidentally committed and deleted files. An interested party could find stuff that you're not aware off by looking at HEAD.
> (not that you would allow checkouts on unencrypted laptops anyway)?
That's not my call to make, but I agree on that regard. Reality sadly different from what we both wish.
Well, that goes without saying. But I don't think that security argument is a very poor one compared to the huge benefit of having the history locally to inspect.
We've had instances where secrets were committed to local repositories by accident. It never got past review and into the master branch. If it had, we would probably had taken the effort to rewrite that commit out of the history.
If you go further upthread you'll find that I said "a valid tradeoff, but one I'd keep in mind"
> We've had instances where secrets were committed to local repositories by accident.
That's laudable, but countless examples show that not everyone is that diligent. I'd love if I could lock down some parts of some repos so that they're only accessible by people that I have an elevated level of trust in. (and where I can enforce a certain security level on the laptop).
Sure, then again I would guess that the ones who are not that diligent are not likely to apply those access restrictions that you mention (although the "one revision" advantage is something they would get "for free" with SVN).
If you happen to have - god forbid - a php app that pulls dependencies via composer you have a hard dependency on github since composer pulls practically all code from GH. I don't consider that a good idea, but that's how it currently is. [No, I don't do php and only sometimes have to clean up the resulting fallout]
You really cannot stop all people from being idiots all of the time.
But for precisely what use cases or in what situations? If one is a novice and just want to have source control and versioning, centralized systems are going to have the better cost/benefit.
This seems completely backwards to me. When I was in college, I thought it was a giant pain to source control my homework, because the options I was aware of (since all I knew about was SVN) were 1) public hosting on sourceforge (which was itself a pain to use), which professors were not keen on, 2) find a private host somewhere (not sure I ever did), 3) run my own server somewhere, 4) configure and run a local server. I went with (3) and (4) but it was never an easy or novice-friendly solution, and mostly I just didn't version control things. The local version control model of DVCS would have been much easier.
It's only when working with other people that any extra complexity even rears its head at all, which doesn't come up if you're a novice who just wants to have source control and versioning.
svnadmin </path/to/repo/on/local/disk> followed by svn checkout <file:///path/to/repo/on/local/disk> is all it ever needed.
git != github. I use git every day at work. I don't use github for that repo. If I did, I wouldn't make reliance on it part of my deployment strategy. If I did do so, I hope I would realize that any problems relying on github resulted in were ones I created with that choice. Hopefully there would be some useful benefits from that choice as well.
git currently can't do that because of the way it's designed and built.
But well, anyway we decide to call that beast, a VCS with distributed commits and centrilized (fetchable) history, with a simplified evolution graph (created by the point of view of a central server) would bring 99.99% of the benefit of a centralized VCS, 99.99% of the benefit of a DVCS, and almost no problems from any of them.
I'm sure that you could probably build the system that you are describing on top of git, but you would still run into problems with large files and local commits, even if it was just "commits since last pull/push."
The other part about the simplified evolution graph is completely missing. I don't think one can solve that without completely rewriting the protocol.
Why in the world would you check in build artifacts into source control, especially those that clock in at 300-500 MB?
Anyone checking in 500MB artifacts into git is almost certainly refusing to use git correctly.
It is like somebody who grows up using hand tools, gets handed a power drill, then tries to use it like a pry-bar. You should not use a screwdriver as a pry-bar, that is an abuse of the tool. Nevertheless, many people abuse screwdrivers as pry-bars because conventional hand screwdrivers tolerate this practice.
You might have a legitimate reason for putting 500MB artifacts into a git repo, but I reeeaaally doubt it.
It is a poor craftsman who blames tools that he is intent on misusing.
So you can doubt my use case but I consider it severely impolite to pretend that you know better. Actually you're quite nicely illustrating one of the points in the article.
Further down on the page somebody else also mentions a legitimate use case to version-control large binaries (needed for comparison). Another use-case I've seen is version control rendered video output and keep the comments and metadata attached to the versions. Works just fine with SVN, fails hard in git. Yet another use case for a system that handles binaries better is what the rubygems folks do - they vendor all gems that a particular version of rubygems.org depends on so they can bootstrap without rubygems.org being available. They built a custom solution using multiple git repos which works for their use-case (it's been discussed on rubygems). Arguably, having a system where versioning large amounts of binary data works better than in git would have prevented that issue.
So there are use-cases that are ill-suited for what git can and cannot do - and just because I say I have one I get to be called a bad craftsman by someone who doesn't know the least bit about what I'm trying to do?
And now you're saying that I engage in a flamewar when I point out that I consider that an insult? Please note that I have not insulted Crito.
Maybe, maybe(!) there is an argument were you would need to version huge binaries which you could generate out of the same already versioned sources, but even if there is, there are methods to backup huge blobs, and git is simply not one of them.
No - nor do they need to. But everybody on the internet could just assume that _I_ know them and refrain from saying that "I'm doing something dumb" and "refuse to learn new tools". So I'd also ask you to review the comment of yours - you're doing the same thing - you imply that "Maybe, maybe(!)" there might be a use-case, so as a matter of fact you doubt I did review and choose my tools.
I reviewed my comment, and I'm at peace with it.
"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."
I found SVN literally painful to use, perhaps because it was based around CVS's standards, and CVS was originally a series of shell scripts written in 1990.
Rebase and DVCS are orthogonal concepts. Rebase is a consequence of offline commits, not of decentralization. And I greatly prefer dealing with a `git rebase` issue than the equivalent in Subversion, which is to have your uncommitted local changes get irrevocably modified by the `svn update`, with conflict markers placed in your code and no way to abort the whole process.
git add -p creates the same issue for git (a commit that never existed on disk) and git rebase with squash and/or reodering of commits does as well. That's usually considered best practice.
The problem I often observe with git (pull -)rebase is that people have a hard time wrapping their mind around the fact that all commits change and when they change and in what state the checkout is are when they get a merge conflict (remote HEAD plus whatever was already applied). The conflict is often unavoidable and you can argue that rebase is making it easier to resolve the conflict, but it's harder to reason about than "ok, update does a merge and I get whatever is on the server plus my local changes".
> The conflict is often unavoidable
If the conflict is unavoidable, then you're going to get a conflict regardless of how you go about it (rebase vs merge vs `svn update`). The difference is with `svn update` you can't abort the whole process and start over if you need to, because you've already permanently lost the previous state of your work tree. Whereas with `git rebase` and `git merge`, you can abort and you'll get the exact state you had prior to the command.
Additionally I would like to add something: There are more cases were you need than you think, especially if you haven't learned it. E.g., you start a little prototype to present to your boss. It succeeds, boom, ten years later you have 100 man team working on the same prototype you started 10 years ago. Suddenly you really need forks, branches, some people spend their whole day merging stuff, etc. But hey, you can't switch from SVN because you have chosen it in the beginning and now everybody is using it, all kinds of scripts, tools, and optimized workflows require that you continue to use it.
Some people might think that spending two weeks in the beginning to learn to use a power tool is much better than starting earlier and thereby getting years of pain later on.
In the world of science, I have colleagues who have said this for ten years wrt. LaTeX vs. Word, or even just learning EndNote vs. typing up reference lists by hand. I cringe every time I watch them spend an order of magnitude more time on pure overhead, and always getting stuff wrong, for every single paper they put out.
No. No it's not. "I can't deploy" is different than "I can't work," unless you "move fast and break things" by deploying as soon as you push your code. Even then git allow you to continue to work, even if you haven't deployed your code.
I had that happen a few months ago. Had to push the repo to bitbucket and change where a config file pointed to. It took almost as long as doing a merge in SVN.
> I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them.
Those are very unlike source code. You're not going to want or be able to diff them, or blame them, or view their history. A different tool is appropriate.
> I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain.
Yeah. I see that at about the same rate I saw developers lose data back in the svn days. Git can "wedge itself" but never in a way that induces data loss, IME, in stark contrast to its predecessors.
You can view the history of binary blobs in a git repo.
Accidents happen, but the pattern of making people make highly predictable mistakes and then calling in the experts is the result of not investing on basic training (and possibly not hiring smart enough people, but it's another matter).
By the way, that "wedged" repository in all likelihood has an uncorrupted working copy containing all changes and can be repaired offline: Git is technically so superior to Subversion and TFS that it isn't even fun.
[1]: https://code.facebook.com/posts/218678814984400/scaling-merc...
Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead.
I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.
That's more a social issue. How many projects accept patches that go against their submission guidelines? Or coding style guidelines?
> I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.
I found that particularly weak.
Let's look through them in more detail.
1. Get a copy of the source code
2. Make your change
3. Generate a patch with diff
4. Email it to the mailing list
5. Watch it get ignored
And often enough, you simply don't have access to the svn repo to do step 1.
1. Fork the repository on GitHub
2. Clone your fork of the source code
3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa.
4. Make a new local branch for your patch
5. Go ahead and make the patch
6. Do a commit
7. Push to a new branch on your GitHub fork
8. Go to the GitHub UI and create a pull request
9. Watch it get ignored
3. applies to SVN projects too.
4. is optional (though highly recommended)
But it gets really interesting when you want to do a second, separate patch. Do that svn when you can't commit directly? well, either throw away your first set of changes, or make a complete copy of your whole checkout.
"Submit a patch" is open source's way of telling you to fuck off.
The Github business of creating a whole publicly visible fork just to submit a patch is a bit much. I have some obsolete forks on GitHub which I need to kill off so someone doesn't try to use them.
Mercurial works with email patches. Not only would they accept it, that's the only way to contribute, sending emails to mercurial-devel.
> They'd probably reject it and tell you to issue a Pull Request instead.
Obviously you're supposed to use the project's workflow, but the point is nothing prevents you from setting up a patch model with a DVCS. Quite the opposite in fact, both Git and Mercurial have facilities for automatically formatting and sending patchsets, and for applying trucktons of patches.
Ref: git am, git format-patch, hg export, hg import and hg email
I think the name of the tool is git pull-request.
I'm agree with the author that the Github model of "always fork the repo public" is stupid. Why not simply push to the official project repo and (for unauthorized people) let it show up as a "pull request"?
Peprage farms remembers.
Sorry shelshock.
"We aren’t going to abandon DVCSes. And honestly, at the end of the day, I don’t know if I want you to. I am, after all, still a DVCS apologist, and I still want to use DVCSes, because I happen to like them a ton. But I do think it’s time all of us apologists take a step back, put down the crazy juice, and admit, if only for a moment, that we have made things horrendously more complicated to achieve ends that could have been met in many other ways."
In the next paragraph, the author links to a post that explains how Facebook will soon experience productivity bottlenecks because of their repository size. That post also explains why they don't want to split up their repository and that, "..the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us."
These are not UX gripes and the problems aren't solved by adding more cheap storage.
this is exactly what the author is saying. and he covers your post there much more concisely. all use cases you mentioned are used infinitely less used than the time you want things git make more cumbersome. that's the while point and i think you made your reply after reading only the title of the article.
but the trolling succeed. everyone replied. sigh. even me.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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...
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.
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.
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.
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.
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.
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.
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.
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?
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...
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.
1. Deterministic "whodunnit" as we have AD integrated with. That is needed when you have 220 people using a repo.
2. Partial check outs. Our platform is 6MLoC in total.
3. TortoiseSVN. Sorry there's nothing else out there as good as that. We use it for DMS tasks as well as you can merge word docs etc.
4. Binaries and locking. Works for design workflows and the odd file we can't merge easily (git/mercurial aren't magic bullets for that).
5. Centralised. All our shit is in one place so there's a "single source of truth". Also no patches flying around.
6. Easy to backup and replicate. Svndump into single file. Or svnsync and there's a true copy.
7. Perfect tooling/tracking integration due to the centralisation and hook support.
8. Easy to use for mere mortals (excel/word pokers).
9. Forces backup behaviour. A specific case but we had a couple of people using git and then pushing to our svn. One SSD fail and bang, the guy lost a week of work because he didn't push to master.
Merge tracking is a non issue since 1.7 and if you need to work offline, just create patches and check them in when you're back online. Also our svn instance has been down for 3 minutes in the last 8 years...
I really can't justify a move to a DVCS and lose all the above so I'm quite happy with my sanity.
Backups are important, have people run a daily backup on their workstations (like duplicity, but for a LAN even something like rsnapshot would work nicely). You might think SVN saves you until you find out that they forgot to 'svn add'/ a file (or whatever the equivalent was) and they mistakenly cleaned their source tree and now its gone for good.
1. Yes. When you have 220 people to herd, some of whom are contractors, there is inevitably a probability of a bad egg or two. Human personalities don't scale well from direct experience unfortunately.
2. Will investigate. I think one of our guys tried this and found a number of shortcomings.
5. Until someone doesn't or someone pushes to someone else's repo who then pisses off on holiday (this happens so often on our git projects it's unreal - yes we have a few test git projects on the go as well)
6. Aware of that. However it pushes local branches too which introduces some interesting problems.
7. Yes but on every rev that gets committed? With git people work offline for days at a time and then push to master in one huge chunk and our pre-commit validation would go apeshit (it does a lot of analysis and validation so would result in massive blocking of work if you don't commit early and often).
9. You would have used what you were allowed to ;-) (I tried git-svn and had some problems but they weren't terrible I admit).
Regarding backups of workstations, our workstations are disposable. It's not unusual (at least every 9-12 months) for one to get swapped or upgraded overnight with no notice or blow up and turn up with a base image. "meh" and 20 mins and you're back where you started. The mantra is "if it ain't on the fileserver or the SVN, it doesn't exist". Best to checkpoint your shit at the end of the day either by exporting a patch to the fileserver or committing on your feature branch. Nothing else matters really on a workstation and it needs to stay that way.
Mainly cat herding issues to be honest.
Edit: a final comment... You wouldn't believe how many ways there are to fuck up a software project with 200+ people on it. It's a warzone of competing ideas, personalities and politics. The only way to run it successfully is with an iron fist and strict control. That's probably a large reason why centralised VCS makes sense for some orgs.
TortoiseHG and TortoiseGIT are good contenders.
You have 220 people working on 6MLoC and you think git can't handle this? You are aware that git is used for the Linux kernel, right? I mean, it must be its most famous use case.
2) His organization is very different than what the Linux kernel does. Linux operates in a hierarchical manner where each subsystem has a maintainer that collects patches and sends them up to Linus. This system makes full use of Git's DVCS capabilities but its not perfect for everyone.
it's basically:
> > I'm using that and it satisfies all my needs.
> but if you join the hive mind you can do all those much more complicated and futile work around steps and get the exact same result.
>> "If you say something’s hard, and everyone starts screaming at you—sometimes literally—that it’s easy, then it’s really hard.
I've tried to go back to TFS, SVN and other centralized systems, but I'm too emotionally bonded to having my source control system with me, everywhere I go... Starbucks, Tim Hortons, the Train, sitting on the beach. But I don't delude myself into thinking this is anything more than emotional. I like having it there, it gives me comfort - and there is some convenience.
I don't want to have to worry about "How do I undo all those changes from my last 10 commits and go back to where I started down this path?" Git gives me that nice fuzzy feeling of being able to play meaninglessly with my code until something takes form and if it comes to nothing, I can do git reset --hard 1f3c2047 and I'm right back to where I was before I went down this path of insanity...and if it takes a nice form, I can do git rebase -i and squash all my messy commits into a single commit with a single commit message. I didn't need to branch, I didn't need to clone, I didn't need to do anything crazy, I just fire up Bash and I'm done, no muss, no fuss, no having to be connected to the source control server, no dependence on anyone else... and if I did want to put that code aside, I can stash it or spin it onto another branch before coming back to my original branch and resetting back to a sane commit. It's nice having ultimate control.
But having that amount of control has its drawbacks...you can't expect the ability to drive stick, but not have to learn how to use a clutch and gearshift.
Or if you're a Kiln customer, and their site is taking 4 minutes to load a page, assuming it's not just down...
Sorry, couldn't resist...
Seriously, though, I don't see where the author is going with his rant. It doesn't say much, and almost seems like a snide jab at Git and GitHub.
None of his points are very good. Yeah, it doesn't take a DVCS to treat the whole repo as a unit. But right now they're the only ones who do. A hypothetical patch to SVN doesn't help me much.
Also, I know from experience that SVN is horrible at binary files, and especially horrible at large binary files. I'm not saying Git and Mercurial are great, but they're no worse than SVN.
The entire section about the amount of books and documentation is just silly. There was a LOT more subversion info around than "just the Red book". I owned two books, and I know we had a few different ones floating around the office, not to mention boatloads of tutorials and guides online.
It's also funny how he makes fun of GitHub's git tutorial, but doesn't mention Kiln's Mercurial and Git tutorials. He also rips on GitHub's pull requests, but fails to mention that they work better than Kiln's.
But it's great to see the founder of Kiln telling everybody not to use the technology his company is based on...
1) Rant about a problem specific to you...
2) Provide no meaningful guidance or solution... (Except move back to SVN to solve a problem I don't have)
3) Make it to the top of Hacker News?
4) ???
5) Profit?
Bug reports to users@subversion.apache.org please. Or it didn't happen ;-)
Is this guy genuinely suggesting that people fell in "love" with distributed version control solely because of GitHub? I don't feel old enough to be telling this author to get off my lawn. I mean, GitHub is great and all, but it does not represent the sum whole of all the commits in this world.
Granted, does anyone know the timelines of when DVCS took off (as opposed to launched)? Mercurial and Git were both released a good 3 years before GitHub was launched.
Okay, I looked up more about DVCS. Wikipedia article's history section on it:
History
Closed source DVCS systems such as Sun WorkShop TeamWare were widely used in enterprise settings in the 1990s and inspired BitKeeper (1998), one of the first open systems. BitKeeper went on to serve in the early development of the Linux kernel.
First generation open-source DVCS systems include Arch and Monotone. The second generation was initiated by the arrival of Darcs, followed by a host of others.
When the publishers of BitKeeper decided in 2005 to restrict the program's licensing,[5] free alternatives Bazaar, Git, and Mercurial followed not long after.
Are there a lot of projects that use Git without a hosting intermediary because of genuine advantages? Yes, absolutely. Plenty of core infrastructure and applications, many of which significantly predate Git or GitHub.
Is there a growing subculture of people who essentially equate Git with GitHub and end up completely subverting the "D" in DVCS, incurring unnecessary downtime and who pretend Git/GitHub are the be-all-end-all? Also yes, with circles such as those of HN being overrepresented with "GitHub is your resume" rhetoric and various startups or hip SaaS having GitHub be their single point of failure.
Being the #1 software hosting site in the world does have an effect on demographics, at the end of the day. By now Git and GitHub have an essential, if controversial relationship.
The ASF has a strict policy of self-hosting. So git repos are now mirrored to github from ASF intrastructure, for the github fans who initially suggested the reverse (ignoring obvious problems such as ASF having no influence over what happens at github).
The author suggests that the "tipping point" for Git adoption vs e.g. Mercurial was when Github made open source development a much more gameable, visibly social activity. Prior to that, every OSS project had a web page, a mailing list, a Sourceforge or code.google.com repo, etc. But no single use ID existed for developers across all of those little islands of identity and conversation. Github changed all of that.
Coming from the scientific Python community, I can absolutely attest to the huge long email threads as projects decided whether they were going to stick with SVN+Trac or Mercurial+Bitbucket or Git+Github. (This was before Bitbucket supported git.) In the end, all of them ended up going to Github because of the social stickiness, even though its ticket and tracking system is really primitive compared to what even Trac was able to do.
But what if the central Mercurial server goes down? A big benefit of distributed source control is the ability to work without interacting with the server. The remotefilelog extension intelligently caches the file revisions needed for your local commits so you can checkout, rebase, and commit to any of your existing bookmarks without needing to access the server. Since we still download all of the commit metadata, operations that don't require file contents (such as log) are completely local as well.
[1] https://code.facebook.com/posts/218678814984400/scaling-merc...
Also, even in SF, Internet connectivity is often flaky enough that requiring a network roundtrip for anything to deal with my files is a non-starter. (Right now, downtown SF, and we only have a single Internet provider option. It goes to ~100% packet loss about 20 times a day. We get about 10-15Mbps out to the wider Internet (but 10x more to servers nearby - probably a shitty ISP using HE or something). So it's really quite a negative to need connectivity to do things.
(For the latter, I ended up developing scripts that worked with patches as first class objects, so that e.g. every bug fix that needed to be applied on multiple branches would actually live in a patch file as my personal way of tracking a unit of work.)
As to distribution, I spent 5 years as a remote developer working for a CA company from London. 200+ms round trips and occasional VPN weirdness meant painful sessions with svn. Having a local repo is excellent. Large binaries that constantly change are still a problem though.
I work on several small-ish projects, and due to the leads coming and going, there are a smattering of source control solutions. On a weekly basis, I use SVN, TFS, and Git about equally.
However, the workflow supported by Git is by far the best for me: I can commit locally as much as I want, rebase the commits or just merge them with work other people are doing, bisect if I broke something, and even branch locally to experiment or when I get interrupted by a question or another task.
Neither TFS nor SVN support this at all. With both of them, I can't really check in until I'm completely done and sure I won't break the build or tests. I end up zipping my directory or fighting with patches/shelvesets that don't do what I want.
Now, does the way I want to work require a DVCS? I don't know - perhaps it doesn't in a theoretical sense. However, DVCS is the only one that actually supports that now.
So sure, we all push to the same repository and it could be a centralized system. But what would actually work? What can I switch to? I'm not abandoning Git for TFS or SVN, that's for sure. Nor Perforce which was also painful.
Yes, you convinced me I don't need the "D" in DVCS. So make a CVS that supports local branching, commiting, sane merging and diffing and show it to me! But complaining that I'm not using one of the features of my DVCS has no bearing on if I should abandon it or not.
If you need binary files or otherwise very large repos, or centralized control and auditing, or non-developers to work with it, then git has major drawbacks. However there is so much code in the world—probably the majority—that works incredibly well with the full benefits of having it all in a single git repo.
Having the whole history and the ability to mutilate it at will in a very fine-grained fashion is a power tool. I like it for the same reason I like vim: the learning curve is steep, but the idea is that this is a core tool I can use across programming languages for the duration of a 40, 50, 60 year career. I don't want to conflate something as horrible as svn with a theoretical good centralized VCS, but I have to say that using svn for 5 years I had much less idea how it worked then I did after 1 year of using git. Even though git was a steeper learning curve, the concepts in it are well-defined and the low-level pieces in it have a clarity of purpose which allows some implicit reasoning about the way things work without having to go in and actually read the source. This allows the fluent practitioner to devise flexible approaches to individual problems that a less modular system can not provide.
I see commit messages and history as a fine craft. With git you can commit everything in small units that make sense only during construction as you are still exploring the problem space, then you can rebase it into cohesive changesets with deep documentation and a continuously unbroken build. A centralized VCS user could only achieve the same by withholding intermediate commits; that's okay, but it can become unwieldy for large changes. With git you can use initial commits like a master woodworker uses scrap wood, structuring them one way for building, and then discarding them in favor of finished pieces built to stand the test of time, providing massive forward benefit in terms of documentation/bisectability. Having worked on at least one project with a 7-year history, I can testify that investing in history curation pays huge dividends and can well make the difference between your successors thinking of you as a solid developer or a shotgun-programming hack.
Problem 2: Lots of versions of big blobs. Solution: git clone --depth 1 remote-url
Problem 3: Big commit history. Solution: git clone --depth 1 remote-url
Problem 4: Bad UX. Solution: Write a better UI, or find someone to do it. Linus is not a UX guy and never will be.
Also, the example workflow differences are pretty similar to the differences between the github model and the Linux contribution model. This has nothing to do with DVCS vs VCS.
So, in short, there's no actual fundamental problem with DVCS. Nothing to see here. Move along.
Sure, 'DVCS' in the form of git or mercurial doesn't deal well with binary files, and has large repo sizes. If these are problems, you might be using the wrong tool.
But that's fine; pretty much everybody should be using something like git or mercurial. They're flexible, relatively easy-to-use, and cover almost all use cases. If you need to store large frequently-changing binary blobs, then you are probably in a minority; there's nothing really wrong with git-annex for managing that content.
But this whole thing we're seeing at the moment with people objecting to DVCS utterly mystifies me, as someone who went from CVS to SVN to git and has utterly no interest in going back.
This part doesn't make any sense. If anything, people would want to convince you it was hard to not look stupid for taking long.
That being said the phenomenon clearly exists, but the reason is probably more along the lines of calling everything easy to try look smart in general.
A person who understands something doesn't shout at you that it's easy (nor that it's hard). It just goes and explains it to you.
Now, I have observed cases where someone inconspicuously took a long time to learn something and then claimed it was easy. This was more to elevate one's own intelligence in the eyes of another. As in, "Wow, this is really hard, but Joe said it was easy. He must be super brilliant."
The other prevalent case of this behavior is when reading mathematic proofs. Often times you'll run across a statement in a proof along the lines of: "It's easy to see that X is true," for some statement X. But, X is always an existing result, and so this is really a way to focus on the details of the proof at hand and not get bogged down in proving every single non-trivial step.
In fact, when I was a Mathlete, our coaches instructed us to make use of this approach, even if we weren't 100% sure that X was true. If we were pretty sure X was true, but we couldn't remember the proof, and we knew it would take prohibitively long to derive the proof, then we would make the statement.
Personally I've never even bothered to learn git. I used to use Perforce at work, now I use it for my own projects. It does the job well, why switch?
The author seems to know a lot about many different things. But still it feels like he falls into the same trap as most people: Things never really just work.
Life is always way more complicated than we would assume at first. SVN does not make most people happy, because it is more simple. If it is more simple there are a lot of things it can't do.
Some people do something fast and simple for you and you think it works. But a week later a coworker needs to spend half the week to make it actually work. And even 10 years later you spend a significant amount of work to make it do things it doesn't do by itself.
Learning a complex tool to do a complex task is really getting you closer. Because after you have spent the time learning it you can spend the same short time periods to achieve a much wider range of tasks, solve much wider sets of problems with each solution, etc.
I know that concept does not have to be inherent to the D in DVCS. But for me that was the killer feature. It changed everything for me. The gain from being able to do that dwarfed all the costs of learning Git.
master = Code that is production ready.
develop = Code for staging
feature/XXX = Feature branches.
Where is there room for confusion? It's dead simple and makes working with teams so easy and effortless. I would never join a team that uses something like Subversion or Perforce in these times.
Git sucks for large blob files - no doubt. For those I recommend using Veracity.
Gone are the major performance issues with exponential merges and more recently, pushing large files.
https://www.mail-archive.com/darcs-users@darcs.net/msg18423....
https://www.mail-archive.com/darcs-users@darcs.net/msg18425....
After having used git, darcs is a joy to use.
What Darcs really lacks is a good "Tortoise" client for seamless Windows integration. It was tried (last release 8 years ago; I feel like I can safely talk in the past tense about it) but the userbase has not been large enough to sustain it.
When it worked, it was pretty good. Darcs' UI was close to ideal. The interactive record prompt, for example (which git got after a while with the "-p" flag), was great. The way Darcs was able to infer dependencies between commits automatically and treat it more as a "sea of patches" rather than a linear history meant that it was very easy to work with branches.
The problem was that as our codebase grew, it increasingly did not work. The infamous exponential conflict problem was just one of several bugs and performance issues that ended up costing us a lot of money in lost productivity. The problem was that when something went wrong, you probably couldn't fix it yourself. The only people who actually understood the internal database — not just the files on disk, but how it all fit together, including the "patch theory" — were the Darcs developers themselves, and not many people except David Roundy actually understood it from top to bottom. The fact that it was written in Haskell (which, at the time, was a lot more obscure than it is today) just made things worse.
After a while we also found that the lack of a linear history had major downsides. Patch dependencies meant it was harder to cherry-pick; when you wanted to pick just one commit, it was often impossibly to understand why Darcs wanted to also pick a bunch of unrelated commits along with it, and from there on it got messy (and you increasingly risked bumping into the exponential merge bug). Git's history-rewriting tools cause more conflicts, but are ultimately simpler and easier to understand.
Darcs' tragedy is probably that its performance problems burned so many people that they gave up and left it for Git or Mercurial, never to come back. We might have stuck with it longer, if it hadn't been for the aforementioned issues. On the bright side, even if Darcs hadn't had these issues, we probably would never have had a Darcshub.com, and Git would still have beaten the competition.
Never again.
We switched to git because it made more sense and worked better, because every operation was faster in git, and because the development of the project was sure to progress. Github became popular years after git was already spreading.
That's technically true, but the implication is not. There was less than three years between the launches of git and GitHub. While git was becoming popular, it was just one of several (D)VCS solutions. GitHub is what really separated it from the rest of the pack.
When bitbucket limited to 2GB for repos, this limit can easily be breached on game projects, but it helped to really git submodule out libraries/code. This also encourages resetting history in a new repo every so often when that history is really not needed, like 2-3 versions back or after many months/years. Distributed VCS databases can get immense, but like anything in life, maintenance every once in a while helps. For some projects this is not possible like a linux kernel but for any old web site, app, game etc this is something that you can and should do.
All operations are faster when your DVCS repo sizes are smaller.
And as for git man pages... I have been hacking on Linux and complex codebases for 20+ years at this point but have never been so befuddled as I have been by the git man pages.
Back to the original topic, git is also way more complex than a DVCS needs to be (compare e.g. with monotone, or just about any other DVCS). And any DVCS is way more complex than even the most difficult to use centralized repositories. So I think the OP's point is valid. There is at least corrolation going on here.
People write books to make money. The easier a topic, the easier is to write a book on it. The more popular a topic, the more profitable is to write a book on it. Hence, you get most books on things that are cool and relatively simple.
> 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.
> 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.
> This means that changing a file in a deep directory will require generating new trees for every directory up the chain—and, of course, that figuring out what changed in a given directory requires loading up all the trees going down the chain. Wondered why git blame runs slow as hell on big repos? Now you know.
(is this even true? Git blame is slow because it digs through history)
> Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it.
People will write books about anything because people will read books about anything.
> Indeed, to listen to this, you would believe that open-source development was impossible, or at least absolutely horrible, before GitHub sprang into melodious existence.
The pull request critique is so silly I'm not even going to try.
----
I really don't see how any of his critiques have to do with DVCS vs VCS. Literally none of them. This really is a Git rant.
If you don't like Git, I guess that's fine. The problem with git is it's more building block than slick foolproof user tool, but some of us like it that way. Git is the first prominent example of someone thinking hard about the low-level theoretical implications of version control (the idea of the state of the entire repo as a changeset, the underlying data structures, etc), and then building a tool around it that works well. When I look at SVN, for example, it's not obvious what the hell we were even thinking - there was no theoretical framework, it was just the simplest thing that worked. And it didn't work well. Branches were more of a pain than a feature. So yeah, there's obviously room for improvement, but I don't even understand the complaint against DVCS in general here.
edit: formatting
edit2: or rather, it's about the current state of DVCSes, but I don't see how most of these would be made better by switching back to a centralized VCS and I'm not convinced that improving these are mutually exclusive with having a distributed version control system. I think there's come conflation of concepts going on here.
However, I think it's the distributed nature that leads to the much more powerful branch/merge functionality, which IS top on my list?
(Git's UI is also not one of the things I like the best. It is a mess, indeed. Yes, because it was not originally intended as an end-user UI. So what, it is the end-user UI anyway, and it's a kind of ridiculously confusing and inconsistent one).
It also doesn't help you manage collisions by locking every UNMERGABLE binary file so you know before you edit if someone else is or has already edited the file.
I know you can set local options to make it lock the files but that feels more like a workaround.
You can set an svn:needs-lock property on binaries. It is not a local option, it applies to everyone using the repository. For extra convience, use svn:auto-props (acts recursively) to set it by default on new files which match a particular filename pattern (e.g. match on file name extension). http://subversion.apache.org/docs/release-notes/1.8.html#rep...
EDIT: That said, I agree that some types of binary files really have no place in SVN repositories. One example are release artifacts, as stored e.g. in Maven repositories.
A little off topic: I tend to work on projects by myself, especially since I have more or less turned off my consulting business. I have some git repos that I have been tempted to rm .git, git init, git add remote origin, and git push -u --force origin master. I have deep backups of everything so losing history to save a lot of space would be good. I didn't used to care about disk space but my two favorite laptops have moderate sized SSDs.
Is Git crap? Yep, unfortunately people went with github over bitbucket, despite bitbucket having a much better pricing model and as a result git is what people use for a DVCS.
I would love for somebody to write a centralized version control system that would be a complete replacement for SVN, the way SVN replaced CVS but until somebody does a DVCs is what we have.
I too have been bitten hard by this. Being a mercurial user, I tried large-file-extensions but on a team this leads to file corruption/non-synchronization too often to be practical.
The most practical "solution" I've found is to actually ignore the issue. When your repository gets too bloated, start a new one.
Not sure how repo size is really an issue in the age of multi terabyte personal storage, it's even possible to get SSD of that size without breaking the bank.
The central SVN is much better for tracking versions for release purposes, while the local git has all the benefits of working on one thing than switching to another.
Any thoughts?
And if you don't like the documentation, well, there's more than one way to contribute to an open source project.
And you could make an argument about Git specifically having bad UX in certain ways, but that isn't an argument against DVCS in general.
There are problems and bugs with every VCS out there, but I've never encountered one with Git that left me completely useless for a day, or with a completely corrupted, unrecoverable repository. I've heard of such things happening in Git, but it hasn't happened to me in 5 years of using it. I've had that happen to me, personally, once every 8 to 12 months using SVN. The we thought SVN was a godsend back then was because it wasn't the 3 to 4 months that was SourceSafe or the monthly rate that was CVS.
Okay, I'm being bit hyperbolic there, but not by much.
And you can model centralized VCS in DVCS--evidenced by the fact that many peopled do do that with Github and it's ilk--meaning that systems that can only do centralized VCS are defective. Git can do everything SVN can do, but SVN can't do everything Git can do.
If your central SVN repository goes down, you're pretty much SOL until it comes back, and you might even be SOL if and when it does come back. If GitHub goes down, I'm mildly inconvenienced when I have to add a new remote to my repository when I need to, say, share code with a colleague, or perform a deployment.
The argument about contributions is... it's not about Git or DVCS at all. It's about GitHub and/or bad project maintainers. And he even admits that, but then acts like he's delivered a blow against the general concept of DVCS.
The argument about blobs is an argument against Git, but not DVCS.
I can't speak to Hg or Baz. I've heard they are easier to work with than Git. But I just can't imagine giving up the things Git gives me to go back to SVN. If someone on one of my projects suggested such a thing, it would seriously call into question for me that person's expertise.
I learned Mercurial first and Git still took me longer to grok.
Eventually this will wear off, and we will go back to using the simplest tool that gets the job done. For some jobs this will be DVCS, for others it won't.
That's what I thought.
His point was DVCSs like Git and Mercurial may have been an improvement in lots of aspects of version control system but they have taken some steps backwards as well.
I thought he was kidding about the crazy juice...
Take a look at the remotefilelog extension.