How well do (D)VCS cooperate with workflows involving several people editing files in the same directory?

Question

Imagine because of tradition that your team's preferred development method involved several people with a shared login, editing files on a build server using vim.

[Note that there are well known issues to do with only one person being able to edit a file at once, people going away from their desk and leaving the file locked in vim, system builds/restarts requiring everybody to stop debugging while this occurs. This is not what the question is about]

If source control was to be introduced without changing the workflow, would there be much benefit?

I am guessing that the commit history won't be much use as it will contain all changes by everybody in big lumps. So it wouldn't really be possible to rewind individual changes apart from at a really big level.

Answer 1

That is not how you use a version control system. Adding one on top of this inherently conflict-prone "workflow" would do very little except add to the confusion.

Everyone is supposed to work in his or her own working copy, and then typically commit changes to a central server.

Answer 2

"editing files on a build server using vim" suggests a central repository.

A CVCS (Central Version Control System) could therefore be a better fit.
But Central or Distributed, both VCS tools involve a local working tree (or local workspace) where the remote files are copied, modified and then sent back (on the commit).

You then have to define your "view" with a workspace which is not in the same place than your local view.
A bit convoluted but possible.

That being said, the main benefit would be to see an history of modifications, which can be done by each user one at a time.