RE: Commit hooks and control of bad development practices?

>I see the critical points as these:
>
>1. All changes are "assigned" to a developer.
>2. The code they change must be "current".
>3. The code they check back in must be the code they were assigned.

Perhaps the locking feature (not yet released, work in progress) would solve
#1.

If I understand correctly, #2 and #3 would be in conflict if #1 is not
enforced because someone else could have updated that code, making the
"assigned" code no longer the "current" code. Is that correct?

Because you have someone checking the incoming code, I suggest you put the
"Id" keyword in a comment in the file. This way the version given to the
developer is noted and can be verified upon return.

HTH,

Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 25 21:20:12 2004