84

As you describe it, you already have some sort of version control, though currently there are some issues with it compared to a typical version control: An intentional commit in version control indicates that the developer strongly believes that the current state of the system would build successfully. (There are exceptions, as suggested by Jacobm001's ...


49

Just my personal view: Version control is useful for anything that takes me more than half a day or that involves a lot of trial and error – or both, of course. If it involves two or more people who are not using the same keyboard and monitor all the time, it is essential. The cost of using a formal versioning system, beyond the initial learning curve, is ...


48

The package "gnuit" (GNU Interactive Tools, a file browser/viewer and process viewer) was called "git" in Debian up until 2009-09-09, while git was called "git-core". Therefore, a better graph to look at is: Which shows that the popularity did not rise dramatically (take the green line for the left part until they cross, then take the red line).


47

if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!) And therein lies the source of your confusion and the whole problem in general. You say that merging branches is "fundamentally wrong and silly". Well, ...


38

Version control was always needed, even before you hacked together your "but, we backup really often!" kludge. Version control lets you publish those changes across files that belong to a logical function as a unit. If you need to review "what was necessary for case-insensitive sorting in that mask?", it tells you all relevant changes and suppresses the ...


34

The git package in Debian was formerly known as git-core. In April 2010 the package was renamed to git. More details can be found in this blog post by Julius Plenz or this commit in Debian. Here is a graph that shows the number installs of both git and git-core over time:


26

I was using Darcs for my own projects for a little while. I switched to git during the rapid ascension that your graph is referring to, so here is my observation: Distributed source control systems at about that time were a bleeding edge thing. The so-called alpha programmers were using them on the side, but they fell outside of the radar of most ...


25

It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times. I don't follow svn very closely, but my understanding is ...


25

At my company, we use a separate SVN repository for every component of the system. I can tell you that it gets extremely frustrating. Our build process has so many layers of abstraction. We do this with Java, so we have a heavy build process with javac compilation, JibX binding compilation, XML validation, etc. For your site, it may not be a big deal if ...


22

The History is sacred, the Present is not. You can split your DVCS "tree" in two parts: The past/history which contains an accurate view of how you have reached the current state of the code. This part of the history grow over time The present which part you are currently working on to make you code evolve. This tip most part of the history have about ...


22

Personally, for your scenario, I wouldn't bother even creating a branch, unless I was working on multiple changes, each of which would need to be accepted by the core developers. Just clone their repository and work in it, then make a pull request. If I were to use a branch then I'd rather use named branches. They were designed for this exact purpose, ...


21

Please see my Stack Overflow answer for a very concrete situation where Mercurial (and Git) merges without problems and where Subversion presents you with a bogus conflict. The situation is a simple refactoring done on a branch where you rename some files. With regard to tdammers answer, then there is a number of misunderstandings there: Subversion, ...


21

A different tool is probably not going to solve your problem, I'd say you should read this article, I found it most helpful: http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx I think the main point of the article is summed up here, but please do read it: In The End: Not Really About The Tools In all of the time I’ve spent working with ...


21

There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth". From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...


20

I think the answer is given in the subsequent sentence: Keeping stable and dev code separate is precisely what source code control is supposed to let you do. By using #ifdef blocks, you are emulating functionality of a source control system with a C preprocessor. It's the wrong tool for the job. The downside is that you probably either end up ...


19

Ohloh In a similar style to my Git vs. SVN answer, Ohloh has been crawled (only) three times by the Internet Archive's Wayback Machine, but July 2011 is unreadable: August 2010 Git: 26,485 repositories (11.3% of total) Mercurial: 2,548 repositories (1.1% of total) Ratio: 10.4:1.0 May 2011 Git: 116,224 repositories (35.3% of total) Mercurial: 3,753 ...


18

From my own experience, the following statements are all true: Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git. This is completely wrong if you compare the size of ...


15

Yes. If you replace "SVN" with "Perforce" in your OP you've pretty much got the situation I found myself in when I started my current job, even down to the manual-change copying. Two years on we're on Mercurial and everyone agrees it's been a great change. We have the ability to branch and merge per support case, which is unbelievably useful for QA, and ...


15

There is a great deal of value in using version control even as an individual developer and it could be quite a bit simpler than the backup/file copy based system you have now. Right now, you have the ability to get to older version of the code, but how do you find the version you want? Just the ability to do a diff between revisions will be very valuable....


13

Start Simple git init Check-In Early, Check-In Often Just do what you normally do with any project: "check in" for every set of changes that relates to a particular task or group of actions. If you use an issue tracker, then commit changes that relate to a task every time it's in a stable state (see this SO question on how often to commit). It may not be ...


13

I was a late adopter - switching from Mercurial to Git in around 2010. The reason I believe Git became so popular is because of sites such as GitHub you had a network effect in version control tools. This was previously not seen, as you would share code on a project or company basis. I specifically remember switching to Git and Github because all the ...


12

I do Mercurial consulting and my experience is that big companies spend a lot of time up-front to investigate the pros and cons of DVCS. So when they finally take the jump, they've already been using DVCS for one or two pilot projects and so they're pretty certain that it will work for the rest of the group. However, I do know of one example where Mercurial ...


12

Git: most powerful, steepest learning curve. Support under Windows was not stellar last time I checked. Unless the students are already familiar with it, think twice. Extremely popular so it might be worth teaching nevertheless. Mercurial: easier than git, but still distributed with all the advantages of this (cheap branching, work offline). Should take less ...


12

I work as a Mercurial consultant and I've found that it's not too hard to explain DVCS to new users, provided that you don't confuse them. So what I do is: Emphasize the core principles. The history model in Mercurial is actually very clean and simple. In particular, I find that branches are modeled better in Mercurial than in, say, Subversion. Talk with ...


12

This is certainly a good idea and it is a common method to use for deployment. You might want to use a stable branch for deployment purposes whilst keeping trunk for ongoing development so that you can test the stable branch before you deploy it into production. The only problem can come when you have sensitive information in your code base (such as API ...


12

First of all, the use of feature branches (to isolate the work done on a feature) and CI (to find integration problems as soon as they are committed) are slightly at odds. In my opinion, running CI on feature branches is a waste of time. As feature branches come and go frequently, the CI tooling would have to be reconfigured over and over again. And that ...


12

In a professional environment where there is code written you should always have source control. There is always the danger of an interview candidate asking what you use for version control and refusing the position because of the lack of a reasonable version control system. Also... if you happen to be able to hire a professional they might also have a ...


12

You should probably read through the PEP yourself. Either Larry Hastings is confused or something was lost in communication. The reasons for moving to git and github over mercurial are not technical, but social. A pull request workflow is perfectly well supported with mercurial, but github is the one with the much wider userbase over bitbucket and ...


11

This is an interesting question. Before the analysis, I'll say that bandwidth savings shouldn't be the reason you switch to a DVCS. However, a related point is the load on the server and that will naturally go down with a DVCS: people are simply not using the server as often. When they use it, they use it for "simple" things like push/pull. Heavy-duty ...


Only top voted, non community-wiki answers of a minimum length are eligible