On 12/13/05, Mark Hoogenboom <address@hidden> wrote:
In this case, can the developers solve any conflicts between the HEAD
and the branch they are checking in to, or will that always be up to the
check-in person? The only way I see is: the developers do the merging up
to the actual commit and then hand over the working space to the
check-in person to check and commit - but isn't "handing over" a
workspace violating some CVS principles?
Mark
>CVS can still support this mode of working, if you use the cvs_acls
>script, allow only the administrator (or check-in person) to check into
>HEAD, and allow developers to freely check into any branches.
How does access control provide support for properly handling a
patching procedure? The OP is trying to use CVS to do something
it was not intended to do. There will still be problems with
concurrent development on the same files. If you are implying
that the process should be changed to force all developers to create
and commit their changes to a 'devel branch' and using cvs_acls to
prevent accidental commits to HEAD then I agree. It still implies
that the OP needs to look at their process and make some changes.
Abhay: another method that would probably help if you don't want
to change your overall process is to have developers submit patches to
the cvs admin. The admin can then apply the patches and resolve
conflicts without fear of accidentally overwriting changes.
Regards,
--Russ
>
>- --
>Jim Hyslop
>Dreampossible: Better software. Simply.
http://www.dreampossible.ca
>
Consulting * Mentoring * Training in
> C/C++ * OOD * SW Development & Practices * Version Management
>
>
>
>
_______________________________________________
Info-cvs mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/info-cvs