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

  • Subversion vs CVS
  • how to mirror CVS repository into Git in real time
  • Which SCM can comfortably handle 90,000 files
  • Which is more popular (currently, by recent install base), SVN or CVS?
  • Can I create a pre-checkout cvs hook
  • Reasons to prefer CVS over SVN or Git
  • Git, ignore folder except for some files with certain extension
  • How to undo a git merge squash?
  • git svn https authentication
  • How do I programmatically upload a file to a github repo's Downloads area?
  • invalid credentials - LDAP access error in git community edition
  • Re-use conflict resolution with Git
  • 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.