Steve Willer wrote:
>you could conceivably have a
>post-commit approval mechanism, or run a pre-commit approval mechanism
>(the recent thread "Commit - Approve cycle ?" talks about this).
I'll go track this thread down.
>>Absolutely right. Still, given the situation that developers are "jumping
>>the gun" and making changes to the wrong version, having the "Id" keyword
>>expansion in the file would allow human checking (or scripted if you're
I have several issues with the ID substitution.
#1 Not all the files we have under revision control could be modified
#2 As I mentioned in my initial post, I assume this means all files in
the local working copy will need to be
modofied on each update from the repository. I currently have
44,000 files in my source tree. Ugly.
>>This begs a few questions. It seems like the repository is being "protected"
>>from the developers. If the developers aren't trusted to make responsible
>>code changes, why do they have direct access to the repository? The reverse
>>seems better - make them responsible for the code they change and they will
>>learn the right way to do things.
This is the crux of the problem, the problem developers are actively
trying to subvert the development
rules. It's often not by accident this happens. I Guess an enforced
policy is really the way to go.
I retroactive scheme to look for suspected regression should be fairly
easy to implement in perl. After
validation by a human, some serios butt-kicking should solve the problem....
>>>My reading of his description is not that #2 and #3 is in conflict
>>>with #1, because #1 is to assign the *change*, not the *file* to a
>>>It would then be possible for two developers to have separate
>>>assignments but have to work on the same code files. Basically your
>>>standard situation that SVN/CVS's update-change-merge-commit cycle
>>>works well with.
>>>Marc: This doesn't seem like a problem to me. Any rev control system
>>>like svn enforces #2 inherently. It doesn't prevent against someone
>>>copying an old version of the file on top of their local copy, but
>>>nothing can prevent that programmatically because it may be the change
>>>involves a legitimate reversion.
Yes it may be legitimate, and that makes it a bit more complicated. As I
mentioned above though flagging
them for human inspection would quickly provide a pile of evidence to
confront said developers and management.
I imagine the subvert-the-rev-ctl-system-'cause-I-know-better-games
would quickly stop.
>>>>Perhaps the locking feature (not yet released, work in progress) would solve #1.
It would only work if they synced with the repository, the fact they
don't is the crux of the problem.
The mindset of update-change-merge-commit rather than the
lock-checkout-change-commit-unlock scheme can work
as well or better for us as long as attitudes and practices change.
My other major question:
What changes are made in the repository when a commit is killed by a hook?
This scheme may lead to a lot of rejections the first little while and I'd hate to junk up
Thanks for the input.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue May 25 23:50:16 2004