>> The problem is that the developer will not know that it has been locked
>> until he/she tries to commit. This will waste
>> (your) precious resources (developer time).
>
> Well I dont think so, because the workfolw would be that simple : when the user
> wont be able to commit its modification to the branch, he'll wonder why and
> either read the lock comment or ask the branch manager for instructions. Then,
> he'll switch to the right branch and then commit in peace.
That would work as long as the branches always are so similar that a painless switch can be done. If the branches are even somewhat different, the developer will waste more time on mending the problems after the switch than he/she would have used on for example reading a mailing list and implementing it on the right branch in the first place. (Not mentioning sparing everyone the irritation.)
Remember, a switch is effectively a merge, and merges are not always simple...
> Well, in fact, our most precious resource is time. So, mailing would be too
> slow for that purpose and regular mass email will quickly bother the users.
> Project meetings ... just dont think about it ;)
:-) Hrrmmm. No tool can replace good comunication. No matter how good the tool is.
I'll take the liberty to quote the Subversion Book, http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html#svn.basic.vsn-models.copy-merge:
"In the end, it all comes down to one critical factor: user communication. When users communicate poorly, both syntactic and semantic conflicts increase. No system can force users to communicate perfectly, and no system can detect semantic conflicts. So there's no point in being lulled into a false promise that a locking system will somehow prevent conflicts; in practice, locking seems to inhibit productivity more than anything else."
Anyway, best of luck to you and your team!
Hans-Emil
Received on Mon Apr 3 15:49:27 2006