2010-03-31 7 views
0

Je veux savoir exactement quand utiliser la commande commit, update et merge dans svn. Après avoir extrait un projet et modifié le code, devrais-je utiliser update, commit ou merge pour rester synchronisé?Commandes commit/update/merge dans svn

me corriger si mal im:

update = toutes les modifications de la mise en pension est copié dans votre projet local. Commit = tous les changements dans votre projet local sont copiés dans le repo.

merge = comme ci-dessus, mais vous déterminez la direction?

Quand est-ce que j'utilise chaque commande ci-dessus?

+0

Configurer la subversion est notre travail. L'utiliser appartient à www.stackoverflow.com (ne vous inquiétez pas, nous allons déplacer votre question pour vous) –

+0

Server Fault est pour les administrateurs système et les professionnels de l'informatique, les personnes qui gèrent ou entretiennent des ordinateurs à titre professionnel. Votre question a beaucoup plus à voir avec le développement de logiciels. Voir http://stackoverflow.com/questions/tagged?tagnames=version-control&sort=votes – Zoredache

+2

En plus d'être au mauvais endroit, cette question ne devrait pas être posée. Comment peut-on sérieusement s'attendre à pouvoir utiliser un logiciel de contrôle de version (ou autre chose) si vous ne prenez même pas la peine de lire au moins l'un des nombreux guides de démarrage rapide sur le sujet? –

Répondre

3

Et je cite le SVN Book:

Le cycle de travail typique ressemble à ceci:

Mettez à jour votre copie de travail. Cela implique l'utilisation de la commande svn update .

Faites vos changements. Les modifications les plus courantes que vous apportez sont les modifications au contenu de vos fichiers existants. Mais parfois, vous devez ajouter, supprimer, copier et déplacer des fichiers et des répertoires les svn add, supprimer svn, svn copie et svn déplacent commandes gèrent ce genre de changements structurels dans le travail copie.

Vérifiez vos modifications. Les commandes svn status et svn diff sont critiques pour revoir les modifications que vous avez apportées à votre copie de travail.

Corrigez vos erreurs. Personne n'est parfait, alors quand vous passez en revue vos changements, vous remarquerez peut-être quelque chose qui ne va pas. Parfois, la façon la plus simple de corriger une erreur est de tout recommencer depuis le début. La commande svn revert restaure un fichier ou un répertoire dans son état non modifié.

Résolvez les conflits (fusionnez les modifications des autres). Dans le temps il faut pour faire et revoir vos modifications, d'autres pourraient avoir fait et modifications publiées, aussi. Vous devez intégrer leurs modifications dans votre copie de travail pour éviter les scénarios d'obsolescence potentiels lorsque vous tentez de publier les vôtres. Encore une fois, la commande svn update est la façon de procéder. Si cela entraîne des conflits locaux, vous devez résoudre ceux qui utilisent la commande svn resolve.

Publiez (validez) vos modifications. La commande svn commit transmet vos modifications au référentiel où, si elles sont acceptées, elles créent les versions les plus récentes de toutes les choses que vous avez modifiées ( ). Maintenant, d'autres peuvent voir votre travail, aussi!

+2

Ceci n'explique pas quand utiliser la fusion. – masterxilo

2

Regardons comment « mise à jour » et « fusion » sont différentes:

On suppose l'historique des révisions d'un référentiel X ressemble à ceci:

...->2707->2708->2709->2710->2711 

2711 est le dernier numéro de révision X. Il pourrait y avoir un bug qui a été introduit quelque part entre la révision 2708 et 2711. Vous savez que le bug n'existait pas à la révision 2707. Il aurait pu être introduit à 2708, 2709, 2710 ou 2711. Fondamentalement, vous êtes intéressé de savoir quel commit a introduit le bug. Une façon de procéder consisterait à revenir en arrière (annuler) les modifications dans votre référentiel local à chaque numéro de révision et à vérifier si le bogue existe toujours. Supposons dire que le bug a été introduit en révision 2709. Vous pouvez faire rouler dos de vos commits avec les commandes folllowing:

$ svn update -r 2710 

Le bug existe encore ...

$ svn update -r 2709 

Le bug existe toujours ..

$ svn update -r 2708 

Le bug n'existe pas. Cela implique que la révision 2709 a causé le bogue.

Cependant, vous pouvez également faire,

$ svn merge -r 2711:2708 

La seule différence entre les deux est que la mise à jour svn soulèverait drapeaux en cas de changements locaux et vous faire savoir. Vous pouvez soit accepter ces modifications, soit revenir en arrière de sorte que lorsque vous exécutez svn diff, aucune modification ne soit apportée. D'un autre côté, svn merge résoudrait les différences entre la copie locale et le dépôt. Utilitaire sage ils feraient toujours la même chose, mais ils démontrent seulement ici des différences comportementales.