16

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?

Improve this question
6
  • 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, 2011 at 19:37
  • Apologies if this question comes off as argumentative. It's a product of some recent frustration.
    – Mike Daniels
    Jun 27, 2011 at 19:38
  • 1
    @Mike Daniels: It doesn't (at least to me) as you clearly ask for the advantages.
    – blubb
    Jun 27, 2011 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, 2011 at 8:58
  • SVN have a version per file, or did that change too in the last version?
    – Klaim
    Jun 28, 2011 at 12:14

5 Answers 5

Reset to default
13

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

Improve this answer
3

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.

Improve this answer
6
  • 3
    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, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 0:05
3

There is no advantage whatsoever to per-file versioning.

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

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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