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 ...


35

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:


28

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 ...


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 ...


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 ...


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

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

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

I know it's not exactly the same, but could you use a workflow where you tag the feature branches before ‘closing’ them? For example: git merge feature-wxyz -m "Merge message" git tag closed-feature-wxyz feature-wxyz git branch -d feature-wxyz Of course, you could also annotate the tag (git tag -a closed-feature-wxyz -m "Description of closed ...


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

As other people have said, "now" is always a good time to start using version control. There's so many benefits to using a good version control system it's almost a no brainer. You mention you use Mercurial. Like other distributed vcs, you can always initialize your own (private) repo and work there. Why not try that? If it starts working for you, it might ...


10

Mind that this deployment strategy is not atomic. It might happen that some files are already updated while other files might still be in the old state while the application is being hit. This can cause unexpected side effects. A way to do atomic deployments is by i.e. using symlinks. Create a directory containing the new files. when everthing is ready ...


8

GitHub is proprietary and is hosted on GitHub.


8

From my experience, feature branches are strictly more general-purpose and flexible. The advantage is that feature branches allow for a developer to work on multiple branches concurrently - and even for multiple developers to be working on the same branch, if needed, without confusion ("Why is Joe writing commits on the Bob branch...?"). Using developer-...


8

Good commit messages are underrated, in my opinion, kudos to you for trying to improve in this aspect. I think the primary audience for commit messages are other developers. There might be other stakeholders, but they also need to be quite tech-savvy to look into commit messages anyway. With that said, you should probably start by defining a commit message ...


7

I have used perforce "in anger" i.e. on a project; it is very good for situations in which your source tree is extremely large- dozens to hundreds of gigabytes of source code in multiple languages, binaries (which should not have been checked in), etc. Similar to subversion, it lets you check out only a part of a repository at a time. Unlike subversion, it ...


7

Algorithm works in the following way. You have two repository: local and remote. They both contains a DAG of changelists. The goal of the discovery protocol is to find one set of node common, the set of nodes shared by local and remote. One of the issue with the original protocol was latency, it could potentially require lots of roundtrips to discover that ...


6

The biggest issue that I can see is that it creates a window of commits where things are half-merged and (probably) not working correctly. When you push the final set of local commits, all of those intermediate commits will also apear for everyone else. In ideal world, I should be able to pull any commit and the code should work. If you start committing in ...


6

Very good, especially given perforce's competition (cvs, svn, etc) over most of its life, but no, not as good as Git. I can't speak to hg. While some of this is off-base (the p4 shelf is now an old feature, no, you can't make a dvcs behave just like a vcs, and it seems silly to knock p4 for xcode dropping support) the choice bits about p4 merging headaches ...


6

It's not terribly difficult to set up a pull request flow on a CVCS, it's just that no one does because they don't want to manage a gazillion personal branches on the server. Perforce is one of the rare CVCS vendors trying to address this by introducing features like streams and sandbox. There is one way DVCS distinguishes itself. It gives you more ...


6

Sometimes certain software solutions want to do everything and that drives their doom. Mercurial, Git and others are just focused on being good VCSs, and they are probably the best ones around (mind the advantages that you get from having a distributed version control system). IMHO, if you want: The best bug tracking you go with Jira, Redmine, ... The ...


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