Consejos para usar Subversion y XCode en un proyecto de equipo

He estado trabajando en un proyecto Xcode (iPhone) con tres personas diferentes. Tenemos el proyecto en un repository de Subversion, pero aún no comprendemos completamente algunos aspectos de la metodología de Subversion + Xcode:

1) Cada vez que alguien hace un commit en un solo file, puede aparecer o no en el proyecto de los otros desarrolladores. Aunque es la misma persona que crea los files nuevos, agrega esos files al Repositorio y luego se compromete en esos files. ¿Por qué sucede eso? ¿Alguna sugerencia?

2) Cada persona que está involucrada en el proyecto no puede hacer un "proyecto completo de compromiso" sin causar un dolor de cabeza considerable al rest de los desarrolladores … ¿alguna idea de cómo se debe hacer esto ?.

La metodología de trabajo que estamos tratando de implementar es que solo un desarrollador (generalmente el líder del proyecto) puede comprometer todo el proyecto, pero debe informar al rest del equipo, para que todos puedan estar preparados para recibir un post pidiéndole que descarte. sus cambios y leer los nuevos files del repository.

Necesito sugerencias o consejos sobre cómo manejar un proyecto con múltiples desarrolladores que usan subversión. Hemos leído el manual de Subversion y muchos otros posts en StackOverflow, pero todavía no puedo encontrar ningún consejo útil.

Gracias por cualquier consejo!

La razón por la que los otros chicos no ven los cambios es que no están informados hasta que intentan hacer una "actualización", "confirmar" o "dif" contra el repository. SVN es un sistema de "extracción", el repository no informa nada a los clientes sin un command de ellos.

La comunicación es la key. Si sus desarrolladores son generalmente conscientes de lo que está sucediendo en el proyecto, o al less en su esquina del proyecto si es grande, minimizarán el riesgo de cometer un código que alterará el proyecto.

Insistir en que solo un desarrollador puede comprometerse con el repository es excesivo en mi humilde opinión y es completamente contrario a la idea de utilizar el control de versiones. También podría tener una única carpeta que solo ese desarrollador pueda escribir utilizando una herramienta diferente cada vez.

Asegúrese de que sus chicos hagan un ciclo de "Actualización", compilation, testing antes de "comprometerse". De esta forma, es less probable que cometan código que rompa la compilation. Si solo tienen un poco de cuidado, todos se darán count rápidamente, realmente no hay mucho de qué preocuparse. Buena suerte.

Usted está diciendo "La metodología de trabajo que estamos tratando de implementar es que solo un desarrollador (generalmente el líder del proyecto) puede comprometer todo el proyecto, pero debe informar al rest del equipo, para que todos puedan estar preparados para recibir un post. pidiéndole que descarte sus cambios y lea los nuevos files del repository ". ¿Por qué es eso necesario? ¿Los otros desarrolladores no pueden registrarse o no son lo suficientemente buenos para registrar el código? Perdón por decirlo de una manera drástica: eso es una mierda. Todo desarrollador debe poder comprometerse. Si desea separar a los desarrolladores entre sí, debe utilizar las twigs para esto. Y como ya se mencionó, la comunicación se realiza por svn update / svn status -u etc.