> Svn and cvs are centralized, which makes everything much more intuitive and easier to understand IMO.
For both cvs and svn, creating branches, merging changes from different branches, and switching branches definitely were operations that required a few steps that would not be easy to figure out without reading through the documentation.
The only thing that git had that those programs didn't was the concept of a staging area, which, as I understand it, bazaar and mercurial didn't have (unless you created another copy of the repo or another branch to serve as a staging area). But the fact that people have tried to replicate that feature in the other DVCSs indicates that it's a desired feature, even if it does add some complexity compared to not having it.
> If only we could instead have an intuitive version control system
What makes git any less intuitive compared to svn or cvs? To use either of those or git effectively required reading through documentation to understand what each command did.
> The really easy to understand systems (such as cvs / svn) are too simple and can't do many important things, so those aren't suitable replacements.
SVN internals are more complex than Git. Also there is a branch/merge semantic in SVN/CVS that is a way harder to comprehend and to predict merge outcomes. I think it had a crucial role in Git's rising. Git has Branches like in SVN and painless merging.
> If cvs commit is what you were used to, then I’m sure staging and pushing changes would strike you as a pointless chore.
But using only `cvs commit` would be the equivalent of using a single script with git that adds every single thing in the relevant dirs and then blindly commits it.
In other words, the people coming from cvs and svn and complaining that git added a step for them were either doing an impeccable job of keeping their source dirs clean at all times, or they were implicitly admitting that they weren't keeping track of what they were adding to their own repos.
I would guess there are old projects that fit the latter description. But I know from experience there are old projects that clearly fit the latter.
> I’m old enough to have used RCS, CVS, SVN, then finally Git
I'm old enough to have used CVS, SVN and then a bit of git.
I remember the big selling point to go from CVS to SNV was "you can put binaries in there!" ... which we never did.
And now I see the selling point to go from SNV to Git is "you can do really complicated stuff like rebase".... which we've never done.
For a team who just does run of the mill distributed version control stuff (commits, diffs, blame, conflict resolution), can you explain why git is such a huge benefit over SVN?
> I've heard that git branching is better(?), but haven't seen that being used anywhere really.
How are you merging without branches?
Git is mostly faster and more flexible than svn, and the merging works far better. Unless svn's merging has improved in the past decade or so, which is entirely possible.
When I switched to git from svn, the main differences were: merging was usable, making new branches and switching branches and such were _instant_ instead of many seconds, and I could work more flexibly (git doesn't require being connected to the server).
> When people talk about Git being a “distributed” system, this is primarily the difference they mean. In CVS, you can’t make commits locally. A commit is a submission of code to the central repository, so it’s not something you can do without a connection.
Not just commits - log, diff, status, almost everything I can remember needed to go off to the remote repository for information. Not only was this annoying when you didn't have connectivity, it was slow when you did.
I do occasionally miss the ability to version files individually though.
> With a DVCS, though, we have a problem. You do have the whole history at any given point, which in turn means you need to have every version of every blob. But because blobs are usually compressed already, they usually don’t compress or diff well at all, and because they tend to be large, this means that your repository can bloat to really huge sizes really fast.
You can shallow clone a repository in git. This looks more like 'What should be the default mode for a source control : Centralized or Decentralized ?'. I think it should be decentralized since it requires more discipline.
> Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands.
This could simply mean that it is am amazing piece of technology that everyone loves to talk about it. It could also mean that it is a bit more complex, but that doesn't mean that the complexity is not worth the benefits.
> There is one last major argument that I hear all the time about why DVCSes are superior, which is that they somehow enable more democratic code development
To be perfectly honest, most companies would do fine with subversion and a very good web based user interface. The simplicity and the advantage of not having to teach people set in their ways may work in its favor.
> I don't really understand why git users keep repeating this trope.
You can create a branch in Git without having to touch the main repository. It's a lot cheaper mentally to create a local branch than a globally viewable one. In particular, it's a lot cheaper to create a branch when you don't have to think about whether the work is important enough to deserve one, or if your crazy idea might end up being an embarrassing failure. When a decision only affects yourself, it's a lot easier to be bold.
> SVN has merge tracking, so it Just Works:
SVN can branch easily, and it remembers how a merge went down, but it doesn't know how to merge a branch back into the truck when the truck has since progressed. When SVN merges, it doesn't know if a difference between the two branches is because it was changed on the trunk or on the branch. It just sees a difference.
Git can replay the changes made in the branch on the updated trunk, or vice versa.
I started with CVS. I had been aware of sccs from an early Unix training course, so I knew how diffs worked, but I never used a VCS until I needed CVS. Later I switched to Subversion, which I think is pretty good, for my use-cases. Subversion flags a conflict if your commit against rev1.1 is submitted after another commit to the same file, but against rev1.2. You have to figure it out yourself, or grab rev1.2 and redo your changes. Git has lovely features for dealing with conflicts, much better that Subversion. But in practice, in a team of (say) three working on a feature, and communicating well, conflicts are rare, and easily resolved.
I should have been using revision control since the early days, of course; but I don't think many of us did - it required more storage, and floppy disks weren't cheap.
[Edit] Perhaps I should note that for a time, I had to work with Microsoft's Visual Sourcesafe, over Frame Delay, to a repository across the Atlantic. Those were bad times.
> What has git so fundamentally changed that SVN/CVS don't count as knowledge / experience?
I think git (and other distributed source control systems) changed the culture around branching and forking. So, if you're coming from a CVS world, there is a lot of technology that changed, and the technology changed the culture/methodology.
I.e., if you dropped a CVS user from 1996 into today's world, they would have culture shock, not just a new technology to learn.
> The Git dev model is _very_ different from cvs, svn, etc so the trade offs are less obvious.
I think that the difference makes the tradeoffs using anything other than git, more obvious. I even held out myself for a very long time with svn vs. git and once I switched... I kicked myself for not doing so earlier.
But, like they said in the post... they did need a feature, which is core to svn (incrementing changelog ids) and a workaround in git. Minor in the grand scheme of things.
> I believe there are plenty bridges between CVS and git already implemented, which also allows you to checkout only part of the CVS tree.
How many of them have you used? I've used a couple, to interact with large code bases on the rough order of 300GB. In my experience they don't work very well, because you have to be hygienic about the commands you run or some part of your Git state gets out of sync with some part of your state for the other source control system. So I gave up on those, and I use something similar to Microsoft's solution at work on a daily basis. It's a real pleasure by comparison, and in spite of that I still call myself a Git fan (about 10 years of heavy Git use now). At work the code base is monolithic and everyone commits directly to trunk (at a ridiculous rate, too).
I've heard horror stories about back when people had to do partial checkouts of the source code, and I'm glad that the tooling I use is better.
The idea of breaking up a repository merely because it is too large reminds me the story of the drunkard looking for his keys under the streetlights. The right tools for the right job, sometimes you change the job to match the tools, and sometimes you change the tools to match the job.
Why, these are pretty basic too. Especially if what you want is just to get the code. Having a bit of experience with any VCS will let you skim the relevant manpage and use another VCS in minutes tops.
> including it in an initrd seems excessive.
True...
> Furthermore git downloads the entire repo
Not necessarily? I think you can download just the source files, without any git metadata, turning git into SVN essentially. I'm not 100% sure though, but I'd be really surprised was it not the case.
---
I started my VCS adventure with RCS, then (quickly) moved to CVS, then (even more quickly) to SVN. As soon as DVCS started to appear I switched to bazaar (bzr), then git. These are the VCS I used for my own projects; I probably used a couple more VCSes in a situation where I needed latest code for some project which used something like Mercurial, or Darcs, etc.
In general, I think it's fair to say that Version Control, as a whole, is a basic tool.
> In the past, version control was something that existed but you never had to think about.
I think its the complexity of git that forces you to think about it. It's really not that user friendly, in comparison to SVN for example. Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that).
The big fallacy for me of distributed version control systems is that we all use them in a centralized way anyway (commit loses value, code does not exist at team level until pushed). It just adds another step to your work flow (code->commit->push vs. just code->commit), but the gain isn't obvious.
>We had a simple workflow going, we changed a file and then committed it directly to trunk, before we went to UAT we created a release branch. Life was simple and things worked really well with SVN, you edited a file, committed and that was that.
You can do that with Git.
>With Git and Odyssey it’s a whole process though, we have to create a feature branch, then commit changes to the feature branch, then pull master branch changes, merge the master with the feature locally, push the changes, ask someone to approve/review every little change, then merge the feature with the master remotely.
Based on what you wrote, this seems all about the workflow your company chose to use with git, not git itself.
> Thinking in terms of SVN (or another non-Dvcs) is what I find trips people up over and over again in git.
No, thinking in terms of non-Git is what trips people over. I came from Hg and still had to struggle with Git, because it's CLI is a mess and it's system behind is rather weird.
Plus things like Rebase and Cherry Pick did't exist in Hg (not by default and not three years ago). Lots of it's underlying model still leaks when using, that having good knowledge of it is mandatory.
> On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file! "Because then you can just set up your project as using version X of file A and version Y of file B"
> Even you seem to acknowledge twice as many commands for version control management for the simplest cases.
Well, I didn't really say that regarding the simplest cases. There is one extra command to get something into the central repository, but basic checkouts and updates from the repository are still one command.
I've gone through the "fighting" with git stage, but it was more because I was trying to use concepts that aren't even possible with SVN rather than that git makes things more complicated.
For both cvs and svn, creating branches, merging changes from different branches, and switching branches definitely were operations that required a few steps that would not be easy to figure out without reading through the documentation.
The only thing that git had that those programs didn't was the concept of a staging area, which, as I understand it, bazaar and mercurial didn't have (unless you created another copy of the repo or another branch to serve as a staging area). But the fact that people have tried to replicate that feature in the other DVCSs indicates that it's a desired feature, even if it does add some complexity compared to not having it.
reply