Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Over the past few years I have worked with several different version control systems. For me, one of the fundamental differences between them has been whether they version files individually (each file has its own separate version numbering and history) or the repository as a whole (a "commit" or version represents a snapshot of the whole repository).

Some "per-file" version control systems:

  • CVS
  • ClearCase
  • Visual SourceSafe

Some "whole-repository" version control systems:

  • SVN
  • Git
  • Mercurial

In my experience, the per-file version control systems have only led to problems, and require much more configuration and maintenance to use correctly (for example, "config specs" in ClearCase). I've had many instances of a co-worker changing an unrelated file and breaking what would ideally be an isolated line of development.

What are the advantages of these per-file version control systems? What problems do "whole-repository" version control systems have that per-file version control systems do not?

share|improve this question
3  
I think it's mainly just historically been like that and we are now moving away from file-oriented to changeset-oriented systems, but from today's viewpoint it's hard to understand why people even tried the per-file approach. Excellent question! –  blubb Jun 27 '11 at 19:37
    
Apologies if this question comes off as argumentative. It's a product of some recent frustration. –  Mike Daniels Jun 27 '11 at 19:38
1  
@Mike Daniels: It doesn't (at least to me) as you clearly ask for the advantages. –  blubb Jun 27 '11 at 19:41
    
These two viewpoints are just different conventions. Any argument in favor of one over the other only raises counter-argument from partisans of the other side. For instance, if you want a "whole-rep" behaviour in Clearcase, you can custom your config spec by date. –  mouviciel Jun 28 '11 at 8:58
    
SVN have a version per file, or did that change too in the last version? –  Klaim Jun 28 '11 at 12:14
show 1 more comment

6 Answers 6

up vote 10 down vote accepted

In my experience, there aren't any: "whole-repository" VCS strictly dominates "per-file" VCS.

share|improve this answer
add comment

Per file has an advantage when you build product lines (multiple software products) from the same repository.

Some customer contracting environments require evidence that their code drop ONLY has the changes they wanted, and not other changes. This is pretty easy if the file version numbers are all the same still.

And this is not a random example I pulled out of thin air.

This happened the last time I was shipping software updates to the US army for a system they purchased large numbers of from my previous employer. The dollar value of the contracts were measure in fractional billions of dollars ( back when US dollars were worth much more )

So it does help some times.

Oddly: where I work now ,we ship each customer a different deliverable too.... (And that is not something I decided, in case you were wondering.)

I suspect it's a lot more common in the defence/aerospace space than in shrink-wrap or web apps.

share|improve this answer
2  
But a branch of whole file repository would also meet the same needs. For example, in bzr, branches are completely independent of the mainline until your merge (or share a repository). –  edA-qa mort-ora-y Jun 28 '11 at 7:44
1  
I cannot think of a single situation where branch in a 'whole-repository' system wouldn't better express the required state than relying on state external to the VCS to determine which files to use in a "per-file" VCS. My first job after uni used RCS, a bunch of scripts to version the project and a top level script to version the version scripts - an absolute nightmare, and yes, that was for a military project too. *8') –  Mark Booth Jun 28 '11 at 9:47
    
@Mark Booth, the customer knew what files got changed for what fixes they wanted. So the physical configuration audit was by version control number –  Tim Williscroft Jun 28 '11 at 22:51
    
What I'm saying is that a version + an audited patch requires different information in different places, the VCS and the auditors. With a branch in 'whole-repository' system, those two states are recorded as separate entities. Now the same information is duplicated between the VCS and audit system, and should always match up. git can even differentiate between author and committer, so you can keep an 'audited' repository which where you know both who created the patch (the author) and who audited it (the committer). Provide us with a exemplary situation and I will reverse my -1. –  Mark Booth Jun 29 '11 at 9:53
    
@Mark booth what patches ? they knew their software was this set of files A 1.01 B 1.05 D 1.55 E 1.44 F 1.01 and the SVD for the version they accepted had file-by-file change info e.g. E changed to fix defect 1104, old version 1.43, new version 1.44. Heaven help us if we'd changed F from version 1.01. The situation was yet more complicated because there were actual bugs that got fixed, they they didn't want changes for. These people wanted the minimal set of changes, to pick up only some features cherry-picked from a year of development. Post-hoc bugfix selection. –  Tim Williscroft Jun 30 '11 at 0:05
show 1 more comment

There is no advantage whatsoever to per-file versioning.

The disadvantages on the other hand, are plentiful and manifest.

share|improve this answer
add comment

I could say that the "per-file" version control systems does not have any clear advantages other than the implementation of the VCS. The VCS' coders would be happy to code when it was a "per-file" versioning. I agree to the point that, it came up historically.

share|improve this answer
add comment

There is no advantage on the per-file approach when you have related files. Which is the most common case in a development settings.

In a few peculiar cases -- /etc or . files in your home directory in Unix is the only one I routinely have -- you are handling (mostly) unrelated files. And then having a system which insists on keeping in sync unrelated changes can be a nuisance.

share|improve this answer
add comment

As what you actually want from a version control system is to keep track of how a system changes, and such changes are only coincidentally related to files on disk, not much.

The biggest advantage in sticking with a VCS such as CVS would be that everyone is familiar with it, even if no-one really groks it.

The approach taken by 'git' and others, is more useful and closer to the actual point of what you are trying to do with a VCS, but only once you get used to it!

share|improve this answer
    
CVS and SVN are so similiar, it's hard to know how to use one but not another. The comparison to 'git' feels off since the added complexity comes from the distributed nature, not from the per-file or whole-repo nature. –  blubb Jun 29 '11 at 6:17
    
That's more or less what I said. Familiarity is a reason to keep doing something, even if its not really the best way. The trouble with the SVN/CVS approach is they track changes to files. "Changed 'zig' to 'zag' might change one file or many. The distributed nature of git is a bonus but its not the most important difference. –  Chris Huang-Leaver Jun 30 '11 at 7:44
1  
SVN keeps a global, whole-repository version number that increments for each change-set. SVN change-sets bring together related changes over multiple files. The change-set is the basic administrative unit of SVN, not the file. –  William Payne Jun 12 '12 at 17:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.