Les modifications de code de fusion sans vrai contrôle de source

Question

Nous avons quelques développeurs travaillant sur la même solution VS2005, mais notre contrôle de source est très mauvais. (Notre société utilise Harvest, pour lequel nous émettons un vote de censure).

À l'heure actuelle, nous travaillons tous uniquement sur les fichiers d'un lecteur de réseau local partagé. Évidemment, cela pose des problèmes. Mais nous pensons que c'est mieux que de travailler localement, de suivre les fichiers que nous avons touchés dans un tableur et de tout fusionner manuellement. Quelqu'un a-t-il une stratégie pour fusionner nos changements?

Certains des problèmes existent en raison de la bureaucratie des entreprises (comme l’obligation de récolter Harvest). Ces mêmes politiques empêchent l'introduction de nouveaux outils dans notre environnement. Ainsi, les stratégies qui évitent d’acheter ou de télécharger de nouveaux logiciels seraient plus efficaces pour nous.

Answer 1

Traitez le partage comme s'il s'agissait de votre système de contrôle de source. Faites en sorte que le partage soit en lecture seule, ce qui obligera les développeurs à obtenir des copies locales pour pouvoir apporter des modifications. Vous avez alors une version quelque peu stable à comparer. Cela contribuerait à faciliter la possibilité de "fusionner". " Vérification " code in devrait consister en une sorte de stratégie de sauvegarde pour le fichier (en créant éventuellement une copie du fichier avec un horodatage et un nom d'utilisateur dans le cadre du nouveau nom de fichier) et en remplaçant l'original par la nouvelle version.

Cela étant dit, faire ce type d'activité sans un véritable système de contrôle de code source fiable sera difficile et source d'erreurs.

Answer 2

Apprenez à utiliser Harvest. Il faut un peu d'effort pour que tout se passe bien, mais dans l'ensemble, c'est un excellent système de contrôle de la source.

Answer 3

Une autre possibilité serait Au-delà de comparer à partir de Scooter . Il a une fusion à deux et trois voies et une grande fonctionnalité de diff sur les fichiers et les répertoires. Si vous voulez en savoir un peu plus à ce sujet, écoutez the delphi podcast de Jim McKeith .

Mais, comme la plupart des autres, je recommanderais soit d'utiliser Git, soit d'apprendre Harvest. Si le système de contrôle de code source permet de modifier son application de diff, Beyond Compare serait un excellent remplaçant.

Answer 4

Obtenez git et installez-le localement sur la machine de chaque développeur. Puis configurez les référentiels pour se répliquer.

Answer 5

Il existe deux problèmes distincts: le contrôle de version et la fusion. Il n'y a absolument aucune excuse pour NE PAS utiliser un système de contrôle de version. Si l'entreprise a choisi une solution (quelle qu'en soit la raison), utilisez-la. Ne pas aimer ou ne pas "avoir confiance" dans ce n'est pas une raison valable pour ne pas l'utiliser. Et utiliser un lecteur partagé pour imiter un système de contrôle de code source est bien plus que fou.

La fusion est un deuxième problème. Vous avez simplement besoin d'un outil de différenciation / fusion. Choisissez-en un. Comment êtes-vous allé si longtemps sans un?!

Araxis est un excellent. Coûte quelques dollars. Les utilisateurs de SourceGear distribuent librement leur outil de différenciation / fusion depuis un certain temps (celui fourni avec Vault). C'est aussi un candidat solide. Celles-ci sont les deux que j'ai utilisées et qui, je le sais, sont toujours sur le marché. Il y en a d'autres que certains ont déjà mentionnés.

Tout fusionner à la main n’est pas une solution tenable. Combiner cela avec pas en utilisant un VCS est une recette pour un désastre.

Answer 6

Vous allez probablement devoir télécharger quelque chose à moins de vouloir le faire à la main. Je recommande vivement Winmerge . C'est gratuit, open source, et probablement mieux pour vous un petit téléchargement qui ne gâche rien.

Answer 7

Il existe un outil de ligne de commande unix standard appelé fusion qui fusionnera assez intelligemment deux ensembles de modifications dans un fichier. La syntaxe est la suivante:

merge mine older yours

Où " mine " est le fichier contenant vos modifications, " old " est le fichier d'origine, et "votre fichier". contient les modifications de quelqu'un d'autre.

Vous ne savez pas vraiment si vous avez une boîte UNIX (ou Mac OS X) pour le faire.

Answer 8

Cela pourrait ne pas être une option viable, mais vous pourriez peut-être utiliser un système distribué tel que bazaar , < a href = "http://git.or.cz/" rel = "nofollow noreferrer"> git , ou Mercurial .

La raison pour laquelle je suggère ces solutions est qu’elles sont très peu onéreuses et peuvent être utilisées avec d’autres systèmes. Je sais qu'avec Bazar, le référentiel est simplement un dossier caché ajouté au répertoire.

Answer 9

Travailler à partir d'un lecteur partagé n'est pas une bonne idée et obtient le vote "aucune confiance".

Il serait trop facile d'écraser les modifications des autres, vous n'avez aucun suivi des modifications, aucun moyen de créer une branche ou une étiquette / étiquette, etc.