0
Suppose I have a file on my folder checked by subversion.
Now, If I start to edit the file (I mean, I see the yellow cue ball on it) I'd like that other people that can access to this file through svn can't open and edit it.
Is it possible?
markzzz
Posted 2011-06-16T07:55:24.837
Reputation: 623
1
You can request a lock on it. People would be able to edit their local copy but can't commit until lock is release. So they need to wait for your commit, then update/merge and commit after that.
If this is difficult file type to merge, it would be good that everybody request lock on the file before starting any modification, so that if someone has already a lock, other user would know that prior to edition.
M'vy
Posted 2011-06-16T07:55:24.837
Reputation: 3 540
Oh, looks interesting. How can I do this? – markzzz – 2011-06-16T08:03:29.780
"Get Lock" menu item of tortoise :D – M'vy – 2011-06-16T08:06:56.533
But Can I do it automatically every time I start to edit a file? – markzzz – 2011-06-16T08:17:01.480
Probably not. By the way, you should use that technique for last resort cases only with file that can't afford being merged (because of difficulty to do it). It is not a mean to avoid doing merges! Do not do it for a source file / text file! Your collaborators will thank you for this. – M'vy – 2011-06-16T08:24:07.047
uhm...I don't know about merge. The problem is when I try to commit my local copy of a file that has been edited by another user. Example: I checkout it, I edit it (and I don't commit it). Meanwhile another user checkout it, edit it and commit it. Now, I can't commit my version. Merge can resolve this trouble? – markzzz – 2011-06-16T08:29:18.357
When you try to commit, svn should said your local copy is outdated. So you can do a svn update on it. Then if the changes your partner made do not impact yours (e.g. you've modified two different paragraph) then merge is automatic. Else, you can edit conflicts to check what he did in parallel of you modifications. Then you resolve conflicts by giving some orders like : keep that, keep this, dismiss that. You mark as resolved and commit back. See the svn documentation on this, there are a lot of tutorial around the internet. – M'vy – 2011-06-16T08:37:35.173
That's I mean : it's hard sometimes check the conflicts and resolve it manually. That's why I like that lock, but it isn't automatically :( – markzzz – 2011-06-16T08:51:23.800
It's meant to be manual. Code versionning has this ability to let programmers work in parallel. Lock breaks this, thus it is inefficient. You will just end up with angry colleague asking you to stop locking files because they want to work. Maybe you can solve problem by working on different branches and have someone in charge of merging all the codes at the end of developments. – M'vy – 2011-06-16T08:59:04.360