Version control system capable of handling file moves?

I’m looking for a new version control system for my software company, which is fairly small. Thus far, I have been using CVS, but I am a little bit OCD about reorganizing file structures all the time, and as a result, I seem to always be at version 1 of all my code (since changing directory names throws CVS’s versioning out the window). Is there a version control system that is more aimed at the development phases (where the project directory tree is constantly changing) or do I need to buckle down and start writing my own? Basically, I need it to track versions of files based on something other than its physical file path, so that moves do not impact a files version information. Any suggestions would be much appreciated. Thanks!

Lukas Rezek

  • Is there a way to prevent code comments to be marked as changes in the diffs obtained from version control? (CVS/SVN)
  • What are some concrete business cases for a CVS to Git migration?
  • How can I keep git cvsimport from skipping patchsets?
  • Is there an (open source) VCS that can work with a whitelist instead of a blacklist?
  • How to get a list of tags created in CVS repository?
  • Merge two git repository histories
  • GitHub collaborators cannot download private repo via NPM package
  • setting up github ssh on windows 7 machine
  • Detecting conflict on git rebase
  • How should I update the version inside my pom.xml when releasing using git flow?
  • Git for windows version 2.5.3 not able to push changes
  • Another git process seems to be running and thus cant commit
  • 6 Solutions collect form web for “Version control system capable of handling file moves?”

    Subversion, Mercurial, Bazaar and Git all support moving files around while keeping it’s history.

    In Subversion, you would use svn move (see Subversion: Moving Directories with History).

    In Mercurial, you would use hg rename. But you will need to remember to use hg log --follow FILE to see the full history (see In Mercurial, “hg rename” works but the history doesn’t follow the file?).

    In Bazaar, you would use bzr mv (see Renaming files and folders with Bazaar Source Control and Bazaar: Moving files after the fact).

    In Git, you would use git mv. But you will need to remember to use git log --follow FILE to see the full history (see Is it possible to move/rename files in git and maintain their history?).

    Create a sample project that you can use to test each tool, give things a try and see how they work for your proposed workflows. Have everyone that would need to use the tool go through the same exercise, compare notes and come to a consensus as to which one fits your needs best.

    Almost any would do: Subversion, git, Hg to name the most popular.

    CVS is blatantly obsolete. Grab anything starting from Subversion (look for the svn move command) down to modern DVCS systems and you’ll be a lot happier.

    Bazaar specifically advertises its good support of renames. They mention renames in their ‘Top 10 reasons for switching to Bazaar’

    Git, Mercurial, SVN (and more) support them as well.

    Sometimes you will need to pass an extra flag to these systems to ‘follow’ renames, though all the information is saved.

    As Antti mentioned, the DVCS options (Mercurial, Git, Bazaar) track content rather than files, so the support comes a little more naturally with them.

    One defining feature of git is that it tracks content, not files, which sounds like exactly what you are looking for.

    Subversion, on the other hand, often has problems when moving files, especially when using branches.

    Git does this as discussed in Getting Git to Acknowledge Previously Moved Files. git log --follow FILE will ensure display of a log across file relocations.

    Git Baby is a git and github fan, let's start git clone.