Prevent users from overwriting each other in svn
I am using subversion for version control.
I often see cases where commits overwrite each other. In git this is prevented as you cannot push until you pull if your local repo is out of date. Is there a similar mechanism in subversion?
eg.
-
Bob updates his working copy by updating svn. He has been working on some changes to file A for several days.
-
Meanwhile, Alice updates her working copy and makes a small change to file A, and then commits it on the same day.
-
A day later, Bob commits his changes - this will not include Alice's changes in file A - overwriting and deleting Alice's changes. When Bob makes his order, he doesn't receive any warnings, no conflicts, or any indication that he should have updated first since the repo has changed.
-
Bob does not intentionally touch any of the lines of code that Alice changed, but since his working copy does not contain Alice's code when he commits it, the result is that the repo only has Bob's changes and Alice's have disappeared.
Although Bob and Alice have a process that means they have to use the svn update before they commit, it seems (to Bob) that svn doesn't enforce this, and Bob often forgets.
How can we prevent this?
[Edit] Thanks to everyone who has abandoned them so far. It looks like you are all saying the same thing that what I am describing cannot happen. Unfortunately my experience with svn, using different clients and different svn versions for several years (on and off) is exactly the same as above. It looks like there is a fundamental thing I am missing about svn so that it doesn't allow code to be commented out when your working copy is out of sync. Too often I've had to believe that svn can prevent it, despite all the answers here. So something disgusting - I need to figure out what - does anyone have any suggestions on how the described effect might occur (without Bob deliberately deleting Alice's code and then lying to the world)?
PS: I'm Bob.
source to share
While Bob and Alice have a process that means they must use the svn update before committing, there is no technology to ensure this, and Bob often forgets.
It's because there is no technology that can completely protect you from users regardless of what they are doing.
Meanwhile, Alice updates her working copy and makes a small change to file A, and then commits it on the same day.
A day or later, Bob commits his changes - this will not include Alice's changes in file A - overwriting and deleting Alice's changes.
Bob cannot commit without starting svn update
, and if he changes what Alice changed, it will cause a conflict for Bob to resolve. If Bob can't do it on his own, yes, Alice's work might be lost - but it's a "people" problem, not a technical one . No software can stop Bob from mismanaging code conflicts.
source to share
[Edit] Thanks to everyone who has abandoned them so far. It looks like you are all saying the same thing that what I am describing cannot happen. Unfortunately my experience with svn, using different clients and different versions of svn for several years (on and off) is exactly the same as above. It looks like there is a fundamental thing I am missing about svn so that it does not allow code to be commented out when your working copy is out of sync. Too often I've had to believe that svn can prevent it, despite all the answers here. So something disgusting - I need to figure out what - does anyone have any suggestions on how the described effect might happen (without Bob deliberately deleting Alice's code and then lying to the world)?
Bob / Hippyjim,
I have this scenario occasionally with users on my team where they have this same problem and they swear the tool was not alerted. I'm still trying to figure this out, but I'm pretty sure they are doing something in a way that makes them overwrite their changes without knowing it. Here are the two scenarios I see with this:
1.) Bob checks revision 100. Alice commits change, revision 101. Bob tries to change it and has to update, but now has conflicts. Bob is overloaded with conflicts and makes one of these mistakes:
... 1.a.) Before the upgrade, Bob copied a backup of his modified file and is now copying it back to his working copy.
... 1.b.) Bob chooses "Use this entire file" in the merge tool in his version without actually looking at conflicts.
... 1.c.) Bob manually modifies the copy working file and manually removes the unified diff text that the tool puts into the file.
2.) Bob is working on the source code in two places. One place is SVN tied, maybe not (maybe a website, on a different computer, or in a different folder) - or maybe it's a working copy of a different branch / repository. Sometimes changes are made elsewhere. Bob updates his master working copy like a good boy. Bob realized that he had made changes to file A in one of these sources. He copies and pastes the file into his working copy and commits.
In any case, these are learning problems and are caused by poor practices.
Regarding (1.): not understanding merge and conflict resolution can trigger these scenarios.
Regarding (2.): Copying and pasting is a bad idea unless you are very careful when working with the SCM. The system does not know if you copied the old old changes or pasted all these old changes manually. Making copies or backups of files also causes problems (copying the file and creating a ".bak" version is something I sometimes see for "old school" developers) - and it shouldn't be necessary, since the SCM system shouldn't allow you lose code If you are not using the tool merge tools, you can trick the tool so you can overwrite old changes.
These are the scenarios I've seen from inexperienced developers. Even great developers sometimes struggle with difficult conflict resolution.
One final thought ... which SVN client are you using? I don't know of anyone that couldn't warn about an outdated working copy (as did other commenters). I've worked a lot with the SVN command line on Linux and SlikSVN and TortoiseSVN on Windows.
source to share
I am still confused about your script.
Bob updates his working copy by updating svn. He has been working on some changes to file A for several days.
Bob updates, we will read a clean working copy and make changes to file "A". Understand. For the sake of argument, let's assume that Bob's working copy is based on version # 100.
Meanwhile, Alice updates her working copy and makes a small change to file A, and then commits it on the same day.
Okay, Alice updates to version 100 and changes it. She is making revision number 101.
One day later, Bob commits his changes - which will not include Alice's changes in file A - overwriting and deleting Alice's changes. When Bob commits it, he receives no warnings, no conflicts, or any indication that he should have updated first since the repo has changed.
Okay, you lost me here. Bob's working copy is based on revision 100. However, the most recent version for this working directory is revision 101. Bob cannot execute unless Bob updates version 101.
Having to update before you make your commit is a big, awkward hint, hitting the developer right on the kiss. This is a warning that your path is fraught with danger: someone else is working on the same as you. Caution! Caution!
At this point, Bob had to do svn log
to see what was changed and why. Perhaps Alice was fixing the same bug that Bob was working on. Perhaps Alice was working on a slightly different bug. Bob should have seen that Alice changed file A at that moment and even the lines that she changed.
However, Bob would need to update, and Bob would see that file A was merged and not just updated. That the lost space robotic hazard would represent a type of Robinson warning.
This is very hard to ignore, especially if Alice changed the line that Bob was working on. This would lead to a merge conflict. This is overheating of the reactor core - the explosion is Immanent. Of course, Bob could ignore this warning. They also did it in Chernobyl.
Bob could manually return Alice's line. Or, if a merge is required, simply used its revision to overwrite Alice's changes. This is not done by accident.
Nothing prevents Bob from rolling back changes. Bob could go through the entire Subversion log and delete all of Alice's commits. There is no version control system that does not prevent users from deleting changes. If the change is bad, you want it back.
Perhaps the problem is that Bob was making some very subtle changes to file A. Perhaps file A is an icon or gif that Bob is painstakingly modifying. Bob is an artist. Alice's changes will just cause problems with what Bob was doing.
If this is the case, Bob can lock file A. In Subversion, file locking is usually advisory. However, when Alice wants to change her, she sees that file A is locked and Bob has a lock. Bob can even comment on the lock.
This would be a testament to Alice that she should work closely with Bob on this change. However, if Bob decides to travel to Bermuda within two weeks, Alice can steal the castle and still make the change.
source to share