Does Source Control Have Any Provisions For Preventing Old Code From Overwriting New Code?

Question

I'm sure that there is a similar question like this already in existence, but I didn't see one that matched closely enough, so here goes...

• We use a third party company to host our site and do most of the code updates and the code is maintained in a Git repository. However, we haven't been too happy with the job they've done, so we've outsourced more and more projects to other companies.
• These other companies maintain their own staging servers and I send them updated versions of the source code and the database as frequently as possible, but in most cases they don't always start each project with the absolute latest version of either.
• Due to a backlog, we recently had an issue where a project that was submitted by that company didn't make it to our staging server until about a month after it had been submitted. So when these files were copied to the staging server, the file that is used by the rest of the application was about a month old and there had been quite a few updates to it in the interim.
• So when this file went to the staging server, a lot of the recent updates were not present and functionality that had gone live on production was missing from staging. Some of the missing functionality wasn't immediately obvious because you had to be in a certain mode to notice it was missing, so it wasn't detected right away.
• I should also mention that even before we had outside companies start working on projects, this was still a problem. Old code would frequently replace more recent updates and then we would have to pay this company to correct the problem and redo work that was already completed.

Obviously, sites that are worked on by multiple developers must face this problem on a continual basis. Is this a case where the company that controls the process employs a questionable methodology or is there really no good way to prevent this from happening? I feel like I'm stuck in a Twilight Zone version of the Springsteen song "One Step Forward, Two Steps Back".

Thanks in advance for any replies. Much appreciated!

Answer 1

Most version control system have a requirement that code be up to date before changes can be applied. It appears your company may be circumventing this my replacing files rather than applying patches.

If you aren't allowing access to version control, then you should be accepting patches rather than replacement files. It is not uncommon to have a secondary public(ish) repository that can be synchronized with. Approved/verified changes are then pulled into the release repository.

It appears you are using GIT, so the other companies should be pulling changes from your repository. They should be pushing releases back to you as a patch. With GIT, you need to resolve conflict before pushing changes.

Some subjects you should become familiar with:

• Workflows for version controlling source code.
• The standard GIT work practices.
• Branching strategies.
• Versioning techniques for binary data.

To prevent conflict before pushing changes, you need to pull the changes from the remote repository. (This is the up-to-date check.). Any conflicts are then local, and need to be resolved locally. Until they are resolved, you can't push your change. Other revision control systems handle this differently, but generally require you to have an up-to-date copy of the files being modified before pushing/committing changes. You can still replace files with your version, loosing any other changes that occurred since obtained. In this case, you can still find all the lost changes in the repository and prepare a patch.

I use a workflow includes updating my copy of the source frequently (daily, or at most weekly). This ensures my code incorporates any other changes. It also reduces the window for introducing conflicts.

When using revision control, source code conflicts tend to be relatively rare as changes are usually to different files, or at least different locations in the file. As a result the patch will be applied with no issues. A subset of conflicts consist of the same change being applied to the same code by two different developers. If the formatting is identical the patch will apply, skipping the already applied change.