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
>>strict/disciplined).
>>
>>
>>
I have several issues with the ID substitution.
#1 Not all the files we have under revision control could be modified
this way.
#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
>>>developer.
>>>
>>>
>>>
Corrent.
>>>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
the repository.
Thanks for the input.
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 25 23:50:16 2004