How to use SVN to make our code in sync?

Question

I am use tortoiseSVN to synchronize our code. But recent I found that there is something that is not so convenient. When i modify a file, let's say a.jsp, and my colleague might also modify this file, a.jsp, and this may result in conflict, and any one of use need to checkin the his code first, and the other one will need to update to latest version, and then resolve the conflict one by one, and this is really error proned.

So i need some function in tortoise SVN, that can lock the a.jsp when i am editing, and prevent the other collegue to modify the file at the same time. I have tried "lock" function in tortoiseSVN, but it doesn't work, when i lock the a.jsp file, my colleague still can modify this file at the same time without any promotion and alert, just like " your colleague are modifying this file, please modify until the check in" ...

is there any better solution ? Thanks in advance !!

Answer 1

Tortoise has a "merge" option that you might want to try once you update your code with his changes.

Answer 2

Yes, there is a better solution, it consists of 3 parts:

1. Never lock, you don't need to
2. Don't work on the same file, or at least the exact same part of the file, at the same time as someone else
3. If you do, be happy to merge.

Merging is a typical part of using a source control system like SVN. You shouldn't be afraid of it, you should embrace it happily.

Generally, the merge can be automatic, unless you are working in the extra same area. In this case you must make the changes manually (but the diff tool, in TortiseSVN, will help you with this).

I would suggest that if this is happening a lot, you re-evaluate how you are assigning out work within your project.

Answer 3

There is a practice amongst SVN users (especially agile SVN users) called "The Check-In Dance". This simple practice can cut down immensely on the amount of conflicts you have when checking code into an SVN repo. It goes like this:

When you're ready to check in some changes to the repo: 1. Do an update first to get everyone else's changes. 2. Run your build script (or just compile if you have no build script) 3. If all is well, commit your changes.

Locking causes it's own set of problems, not the least of which is that people tend to forget to "unlock" the file leaving everyone else totally unable to work if they need to change that file.

Merging conflicts in SVN is fairly easy to do, so using locking should become a non-issue for you once you get used to using TortoiseSVN.

Hope this helps, Lee

Answer 4

As mentioned by others, the most flexible workflow is one where you don't need to lock. However, if you really do want to lock a file, Subversion provides this capability.

Add the property svn:needs-lock to the file(s) for which you want to require locking, and set the value to * (I don't think it actually matters what the property value is). Then when checking out or updating, Subversion will mark those file(s) as read-only in your working copy to remind you to lock them first.

You would lock the file with Subversion (I see you already found this option, but it doesn't do anything for files that don't need locking) which will make the file read-write on disk. Then make your changes. When you check in the file, Subversion will automatically release the lock (but there is an option to keep it if you like). Then the file will be read-only in your working copy again.

Note that locking in Subversion is "advisory" only. This means that anybody else can force acquisition of the lock even though somebody else might already have it. In this case, the workflow is still supported because somebody may still need to merge their changes as they would without locking.

Finally, locking files is the best way to deal with non-text files in Subversion, such as image files or MS Word files. Subversion cannot merge these types of files automatically, so advisory locking helps make sure that two people don't try to edit the same file at the same time.