2

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!

Cheers, Lukas Rezek

SuperTron
  • 4,203
  • 6
  • 35
  • 62
  • 6
    You found the `git` tag. Did you do a bit of research on that before you posted your question? – Mat Oct 19 '11 at 18:37
  • 2
    SVN will handle it ... *if* you move the files by `svn move`. For me, the "real question" is how to have SVN (or whatever SCM) *automatically find out* what files were moved during the change-set process and use said knowledge as appropriate ... but that is a different question. –  Oct 19 '11 at 18:38
  • 7
    The answer to "do I need to buckle down and start writing my own?" is rarely "yes" (unless your last name is Torvalds) – Nate Oct 19 '11 at 18:40

6 Answers6

6

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

alf
  • 8,377
  • 24
  • 45
3

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.

Ondrej Tucny
  • 27,626
  • 6
  • 70
  • 90
2

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.

Community
  • 1
  • 1
Go Dan
  • 15,194
  • 6
  • 41
  • 65
1

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.

jwd
  • 10,837
  • 3
  • 43
  • 67
1

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.

Antti
  • 11,944
  • 2
  • 24
  • 29
  • What kind of problems have you experimented with Subversion? – Ernesto Campohermoso Oct 19 '11 at 18:50
  • 2
    @Ernesto Campohermoso: Every time I've tried to do a merge in Subversion (even in recent versions), it might work the first time but tends to go badly wrong after a short time. One gets error conditions such as "tree conflict" that are maddening to resolve (and usually result in saving the files, wiping the checkout, making a new one, copying the files back in, and trying again). I no longer recommend Subversion for any workflow that involves merging. – Greg Hewgill Oct 19 '11 at 19:01
0

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.

Community
  • 1
  • 1
Jeff Ferland
  • 17,832
  • 7
  • 46
  • 76