> Ok, How does this sound --
> If a person clicks "get lock" on a file that doesn't have "needs-lock," then...
> - During the "get lock" dialog, display a checkbox (selected by default) to also set "needs-lock."
> - If the person leaves this checkbox selected and hits OK, then...
> - Set the needs-lock property.
> - Commit
> - Get Lock.
You can't work around it this way either. There are several reasons why what you are suggesting won't work in reality.
1.) To do all-in-one-actions containing automatic commits is a bad idea. It has been discussed many times before and always been turned down. What do you do if the commit fails? What happens to the atomicity of subversion?
2.) It won't solve your problem. Even if you set the "svn:needs-lock"-property and commits, this won't be known by the others until they have done an update. This means that when setting the property on a file you will be in a "unstable" state until everyone has done an update and received this change. Until then the property is as useful as the lock by itself. Point being: Everyone needs to have the property on the file in their WC *before* you get the lock. There is no other way to guarantee this than setting the property when the file is added.
3.) This spontaneous locking of random files is probably a bad idea altogether. (As pointed out by others on the list as well.) Why do you need this so badly? Maybe you should sit down a while and ponder if you might have some issues in your workflow or communication that could be improved?
> - If the person chooses "Nobody can edit without a new lock" then...
Also please note, that by default locks in Subversion are breakable. They are designed as a feature to aid communication. Everyone *can* (edit/)commit. They are just informed and encouraged not to. (Which hopefully should be enough.)
> Does this sound reasonable to everyone?
As you might have guessed by now: No. :-)
Hans-Emil
Received on Fri Apr 28 08:15:16 2006