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