Sorry, I didn't mention that I agree with you about the ID numbers in
the commit log. I've used that at work for a long time now, and it
works very well.
The developers don't really have unfettered access to the repository.
Every change is logged, linked to the committer, and probably reported
to somebody with authority via email. No changes can be deleted;
changes only add to the version list. If you are concerned about the
level of access to developers, 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).
On Tue, 25 May 2004 13:50:02 -0600, Kevin Williams
<kevin_w69@hotmail.com> wrote:
>
> 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).
>
> 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.
>
> Perhaps I just need more caffeine, I don't know. :)
>
> >From: Steve Willer <steve.willer@gmail.com>
> >To: Kevin Williams <kevin_w69@hotmail.com>
> >CC: dfs@xmission.com, users@subversion.tigris.org
> >Subject: Re: Commit hooks and control of bad development practices?
> >Date: Tue, 25 May 2004 15:27:10 -0400
>
>
> >
> >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.
> >
> >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.
> >
> >
> >On Tue, 25 May 2004 13:19:11 -0600, Kevin Williams
> ><kevin_w69@hotmail.com> wrote:
> > >
> > > >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
> > >
> > >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 25 22:16:36 2004