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
Received on Tue May 25 21:50:53 2004