¿Cómo evitan los equipos sobrescribir el trabajo en los archivos fuente? [cerrado]

Cerrado. Esta pregunta está fuera de tema . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que sea sobre el tema de Game Development Stack Exchange.

Cerrado hace 4 años .

Se me ocurrió la posibilidad de que, por ejemplo, mientras varias personas trabajan simultáneamente en el motor del juego, ¿cómo se evita la sobreescritura?

Digamos que el desarrollador uno está trabajando Audio.cppy el desarrollador dos también está trabajando Audio.cpp, ¿cómo se maneja esto generalmente en equipos grandes para combatir la sobrescritura? (En otras palabras, para evitar que el desarrollador dos abra el archivo hasta que el desarrollador uno haya terminado)

project-management version-control teamwork java 2d collision-detection vector collision-resolution unity directx directx11 directx10 xna ios monogame windows-phone-8 xamarin design-patterns oop xna collision-detection collision-resolution bounding-boxes rotation collision-detection mathematics javascript algorithm separating-axis-theorem xna 2d monogame image xna directx graphics performance opengl 2d 3d c++ directx11 unity c# scale c# xna collision-detection collision-resolution leaderboards scoring glsl srgb tilemap three.js tiled unity physics xml dialog-tree xna c# .net opengl lwjgl vbo physics graphics procedural-generation simulations water opengl java textures lwjgl frame-buffer unity unity 2d collision-detection collision-resolution trigonometry java android libgdx xna c# frame-rate c++ unreal-4 procedural-generation java graphics lwjgl slick c++ software-engineering

— Ethan Webster
fuente

Una de las etiquetas que seleccionó ya es la respuesta.

— Philipp

De hecho, 3 de las 4 etiquetas son una respuesta, pero una es la respuesta.

— MSalters

Relacionado: gamedev.stackexchange.com/q/480

— moooeeeep

Respuestas:

La mayoría de los equipos de desarrollo de software (no solo en desarrollo de juegos) resuelven este problema utilizando el software de control de versiones . Ejemplos son

Todas estas herramientas tienen algunas diferencias, pero el flujo de trabajo básico suele ser así: hay un repositorio central para el proyecto con la base de código completa. Cuando un desarrollador quiere unirse al proyecto, realiza una "compra". El software de control de versiones copia la base de código en su máquina local. El software recuerda la versión actual ("revisión") de la base de código. Cuando un desarrollador realiza sus cambios y quiere colocarlos en el repositorio principal, realiza una "confirmación". Sus cambios se cargan en el repositorio central y se crea un nuevo número de revisión.

Cuando otro desarrollador ahora quiere confirmar sus cambios, pero la revisión que una vez revisaron ya no es la más reciente, el sistema de control de versiones no lo permitirá. El desarrollador primero necesita "extraer" las revisiones que ocurrieron mientras tanto. Esto actualiza su copia local a la versión más reciente en el repositorio central. Cuando hay conflictos (las revisiones intermedias hicieron cambios a un archivo que también cambiaron), el software podría pedirles que resuelvan el conflicto editando los archivos en conflicto manualmente (una "fusión") en caso de que no logre hacerlo automáticamente. Una vez que hayan hecho eso, pueden confirmar sus cambios como una nueva revisión.

— Philipp
fuente

Tenga en cuenta que Git y Mercurial son sistemas de control de versiones distribuidos , que funcionan de manera un poco diferente: no requieren un único repositorio central, pero en teoría permiten que cualquier desarrollador obtenga actualizaciones directamente de cualquier otra persona. Por supuesto, en la práctica, todavía es común tener un repositorio (a menudo ubicado en un host público como GitHub) declarado el "oficial", y utilizado más o menos como el repositorio central en un sistema de control de versiones no distribuido.

— Ilmari Karonen

Esta respuesta también implica que la fusión siempre se realiza manualmente. Sin embargo, la mayoría de las veces el software de control de versiones puede combinar diferencias automáticamente y solo requiere trabajo manual para cambios realmente espinosos.

— jhocking

Evite la discusión extendida en los comentarios, amigos. Este no es un foro de discusión. Utiliza el Chat de desarrollo de juegos si quieres hacer eso. He limpiado varios hilos de comentarios tangenciales.

— Josh

Además, idealmente, cada miembro del equipo estaría a cargo de módulos específicos casi exclusivamente, y solo en casos excepcionales, más de una persona modificaría el mismo archivo fuente en un corto período de tiempo, ya que este flujo de trabajo minimiza la necesidad de fusionar cambios conflictivos. Pero ese no es siempre el caso.

— Nicolas Miari

Los desarrolladores no usan el mismo archivo.

Cada desarrollador tiene su propia versión del archivo, y utilizan un tipo especial de software para administrar su trabajo. Si ambos realizan cambios, el que intenta sobrescribir los cambios realizados por el otro desarrollador se encontrará con un conflicto que debe resolverse, de lo contrario, el software del que hablé comienza a quejarse. En otras palabras, el desarrollador que causa el conflicto, necesita combinar su trabajo con el trabajo del otro desarrollador, y solo entonces se puede "guardar" el archivo.

Esta es una explicación simple para una parte del concepto de control de versiones que de otro modo no sería tan simple .

También hacen esta novedosa cosa llamada comunicación y el software no está escrito en el vacío. Entonces, si no entienden el conflicto, van a hablar con la otra persona o coordinan de antemano.

— Brian

Además de los puntos planteados en las otras respuestas sobre el control de versiones y el manejo de conflictos con fusiones, existen al menos otras dos formas en que los miembros del equipo pueden evitar sobrescribir el trabajo de los demás:

Algunos sistemas de control de versiones (por ejemplo, SVN) permiten el bloqueo de archivos. Esto significa que un miembro del equipo puede tomar posesión exclusiva de un archivo durante un período de tiempo prolongado, evitando que otros miembros del equipo realicen ediciones conflictivas (o, en realidad, cualquier edición) hasta que el archivo se desbloquee posteriormente.

Sin embargo, esto generalmente se usa con poca frecuencia, ya que puede causar una serie de problemas. Puede reducir la productividad (al limitar quién puede trabajar en archivos en un momento determinado) y puede causar problemas si alguien olvida desbloquear un archivo. Además, al menos para SVN (no estoy seguro acerca de otros VCS), bloquear un archivo no impide que otra persona realice cambios en su copia de trabajo, solo evita que cometan sus cambios; esto puede resultar en un esfuerzo inútil si un desarrollador modifica el archivo solo para descubrir que no pueden confirmar sus cambios porque está bloqueado.
Los equipos pueden tratar de asignar tareas a los desarrolladores de tal manera que no tengan más de una persona trabajando en un archivo en particular en un momento dado. Por ejemplo, los desarrolladores podrían ser responsables de una parte particular del proyecto (por ejemplo, representación 3D, red, audio, etc.): si la base de código está bien modularizada, el desarrollador asignado al código de red debería tener poca necesidad de tocar los archivos lidiando con el audio.

Por supuesto, siempre habrá una superposición que debe gestionarse de otra manera.

— Mac
fuente

En el lado positivo, el bloqueo es la única forma en que puede editar un .JPEG u otro archivo de texto no plano. Esto no es una limitación teórica, es solo que las herramientas de fusión generalmente apestan.

— MSalters

@MSalters No es que las herramientas sean malas, es solo que la mayoría de las herramientas de fusión se crean para texto, no para datos binarios. ¿Y cómo resolvería un conflicto si dos cambios modificaran el mismo píxel en un archivo? O peor aún, ¿cómo consideraría los cambios causados por la compresión JPEG? Es un problema muy complejo que puede que ni siquiera tenga una buena solución, por lo que la mayoría de las herramientas de combinación no son compatibles porque la necesidad es muy rara y la funcionalidad es difícil de implementar.

— Maurycy

@MaurycyZarzycki: Cambiar la misma letra es similar a cambiar el mismo píxel: eso necesita una resolución manual. .JPEG probablemente fue un mal ejemplo, ahora me doy cuenta, porque los artistas no trabajan en formatos con pérdida. Pero el problema de fusión también existe con .PNG. Como mínimo, agradecería que las herramientas de fusión pudieran fusionar XML sin romperlo.

— MSalters

@MSalters Claro, con eso puedo estar mucho más de acuerdo.

— Maurycy

@xorsyst: Pruébalo de esta manera: echa un vistazo desde SVN en dos ubicaciones. Luego bloquee un archivo desde la ubicación 1. La ubicación 2 no sabrá que está bloqueado hasta que se confirme o actualice.

— Zan Lynx