... ce que je n'avais pas envie de diviser dans plusieurs postes de questions, car je suppose qu'ils sont fondamentaux, la plupart des gens ici sauront répondre à la réponse.
Je développe depuis plusieurs années maintenant et je n'ai jamais eu le temps de vous en apprendre davantage sur le contrôle de la version. Renommer des annuaires avec différents noms de version semblait toujours assez. Maintenant, j'ai enfin décidé de l'apprendre, mais une terminologie de base et des principes de travail me confondent toujours.
Mes projets sont relativement petits, jusqu'à 10 ou deux fichiers (bien que les fichiers soient relativement gros), et sont effectués à titre non Oo. Je prends souvent une approche, faites-le à un moment donné, puis décidez que cela ne fera pas, alors (réutiliser l'ancien code) réécrire complètement l'ensemble du projet avec une organisation de fichiers complètement différente et une organisation de code interne. Les fichiers disparaissent et de nouveaux fichiers apparaissant entre ces "versions" ne sont pas rares.
Alors voici mes "confusions":
1) Par exemple, comme décrit, j'ai mis la première version en VC. Ensuite, je supprime tous les fichiers et les réécrivez à nouveau. Si j'ai bien compris, ce serait une nouvelle "branche", non?
2) Si je continue à développer cette version, je continuerais à prendre de la sorte à cette "branche"?
3) VC enregistre-t-elle, lors de la sauvegarde d'un point de sauvegarde dans une branche, de tous les fichiers de ou du fait de sauvegarder la différence entre eux?
4) Puis-je facilement obtenir tous les fichiers (dans tout le projet) d'un certain point de sauvegarde d'une succursale ou dois-je le suivre à travers Diff's jusqu'au début? (Je veux juste pouvoir dire: "Ici, c'est le point de sauvegarde - Copiez tous les fichiers dont vous avez besoin pour ressembler à ceci")
5) Qu'est-ce que cela signifie, en termes très simples, à "pousser" et "tirer". Je ne comprends pas la différence entre "pousser" / "tirer" et "commettre".
Si cela importe, j'utilise VS 2008 et je pense utiliser des extensions GIT, car j'ai entendu de belles choses à ce sujet. Est-ce une bonne combinaison et utiliserait SVN (par exemple Visuelsvn ou Ankh) être une meilleure option pour moi, en tenant compte de ce qui précède?
- cordialement, Peter
8 Réponses :
Vous n'avez pas vraiment besoin d'une succursale sauf si vous devez travailler séparément sur deux ensembles de code différents pour le même projet. La ramification est beaucoup plus fréquente dans une équipe dans laquelle la plupart des développeurs travailleraient sur des fonctionnalités à plus long terme dans le coffre, tandis qu'un ou deux créent une succursale pour libérer une fonctionnalité spécifique plus tôt. Ils fusionneraient ensuite cette branche dans le coffre, de sorte que tout le code était à nouveau au même endroit. Ceci est juste un exemple ...
Ma recommandation est simplement de configurer un référentiel de subversion (idéalement sur un autre serveur, mais si cela doit être sur votre machine, c'est mieux que rien), et commettez (poussez) vos changements là-bas. Vous pouvez toujours mettre à jour votre copie de travail locale (tirez) du référentiel.
Subversion fait une diffère binaire sur des fichiers, de sorte que cela ne fait que sauver la différence, pas une copie entière. Cela peut être un problème si vous avez beaucoup de renommés / suppressions (en espion) dans les branches, mais devriez être correct si vous restez dans le coffre.
Si vous êtes inquiet pour ces problèmes, je recommande Mercurial ou Git, qui crée des copies entières (clonées) du référentiel (sans diffs binaire). Mercurial a un peu plus performant de Windows en ce moment, si vous êtes un gars d'interface graphique. Cependant, Mercurial et Git n'ont pas le même outillage intégré que SVN ne le fait encore (avec ankh, par exemple).
J'utilise svn avec ankh pour VS2008 et, en général, je l'aime (surtout ankh!), bien que j'ai été brûlé par le répertoire Delete / Rename Issue dans SVN quelques fois ...
bonne chance!
Noah
incorrect, ce serait simplement une nouvelle révision. La ramification est l'endroit où votre flux de révision "fourchette" dans deux directions ou plus. Il s'agit généralement d'une opération spéciale distincte de l'ajout et de la suppression de fichiers.
Comme avant, vous n'avez pas ramifié à ce stade. En règle générale, vous sélectionnez la succursale que vous utilisez à l'aide de votre outil de contrôle de version. Je recommande vivement de regarder la documentation autour de la ramification pour l'outil que vous souhaitez utiliser.
La plupart des outils de contrôle Versin enregistrent uniquement les différences entre les versions d'un fichier. Certains (notamment CVS) ne feront que cela pour les fichiers texte et les modifications apportées aux fichiers binaires entraîneront une copie complète de la nouvelle version stockée. Notez que cela ne vous empêche pas d'obtenir le dossier complet à une révision donnée, il est purement de savoir comment les données sont stockées.
Vous pouvez obtenir l'état complet à n'importe quelle révision sélectionnée à tout moment.
avec un système de contrôle de version centralisé (CVS, Subversion) Vous vous engagez dans le référentiel et vérifiez dans le référentiel. Avec un système de contrôle de version décentralisé (Git, Mercurial, Darcs, Bazar), vous clonez un référentiel à distance (ou créez votre propre référentiel local), commettez des modifications à ce référentiel, puis vous pouvez appuyer des modifications à des modifications à un référentiel à distance différent ou des modifications apportées à partir d'une référentiel à distance. La distinction est que chaque développeur a sa propre copie du référentiel et génère des modifications de leur copie et des autres personnes pour les voir que ces modifications doivent être poussées à un endroit commun d'où les autres personnes peuvent les tirer. IBM a un décent Introduction au concept de contrôle de la version distribuée. < / p>
Une partie de votre confusion provient probablement de différents systèmes de contrôle de version (VCSS) qui utilisent la terminologie différemment.
Je pense généralement au code dans "lignes". Je commence avec la version originale d'un fichier et enregistrez-la sur mon système de contrôle de version. L'appelle dans le VCS s'appelle un "enregistrement". Le système de contrôle de version l'étiquette avec un certain nombre, tel que la révision 1.0. Maintenant, je compile mon logiciel. Il se casse, alors je dois le modifier. Pour ce faire, je "vérifie" le système de contrôle de la version et le modifier. Maintenant que c'est corrigé, je vérifie le système de contrôle de la version qui le stocke comme révision 1.1. Mon patron veut une nouvelle fonctionnalité, alors je vérifie, éditez-le et vérifiez-le à nouveau, et il est stocké comme révision 1.2.
C'est la "ligne principale" ou "coffre" du code.
Un système de contrôle de version vous permettra d'obtenir une ancienne version d'un fichier en spécifiant le numéro de révision. Disons que je reçois un rapport de bogue de logiciel basé sur la révision 1.1. Je peux utiliser "diff" ou tout outil de comparaison pour comparer 1.1 avec 1,0 et voir ce qui a changé. Peu importe la façon dont le système de contrôle de la version le stocke en interne, je viens de le demander par numéro de révision et je reçois tout le dossier.
La prochaine chose à comprendre est qu'un groupe de fichiers constitue votre projet ou votre solution. Lorsque vous allez compiler votre logiciel pour le libérer dans le monde, vous souhaitez associer une «étiquette» avec tous ces fichiers afin que vous puissiez les traiter en tant que groupe. La plupart des gens utilisent une étiquette numérique, telle que Windows 3.0, Windows 3.51, etc., mais ce n'est que la convention. Vous pouvez étiqueter une version "Hardy Heron" ou "GuSy Gibbon" si vous le souhaitez.
Maintenant, tout va bien si vous êtes un gars qui continue de mettre à jour les choses que vous allez. Mais disons que vous continuez à travailler sur votre logiciel et publiez la version 7, puis 8, puis 9, et vous travaillez maintenant sur la version 10. Mais aujourd'hui, vous obtenez un sérieux rapport de bogue sur la version 7 que vous devez juste résoudre. Donc, vous allez sur votre VCS et demandez tous les fichiers source avec l'étiquette "Version 7". Vous obtenez ceux-ci dans un dossier séparé sur votre disque et corrigez le bogue. Mais lorsque vous allez vérifier ces fichiers, vous avez besoin d'une partie de la version 7, car vous avez déjà ajouté des fonctionnalités dans les versions 8 et 9. Ceci est lorsque vous créez une "branche".
Un exemple pourrait être plus clair. Disons que vous avez vérifié "la version 7" du package et le fichier à réparer était à la révision 1.23. Dans la version 10 (que vous travaillez dans un dossier différent), vous travaillez avec la révision 1.40. Vous ne voulez pas que les modifications de la version 7 entrent dans 1.41, car cela écraserait et détruit toutes les fonctionnalités soignées que vous avez ajoutées dans les révisions 1.24 à 1,40. Vous créez donc une succursale et enregistrez votre fichier modifié comme révision 1.23.0.1. Vous le compilez, et maintenant le bogue est corrigé. Et maintenant, vous devez le relâcher à vos clients. Lorsque vous publiez, vous créez une nouvelle étiquette. Je voudrais étiqueter ce quelque chose comme "la version 7.1" afin que je puisse dire la différence entre le logiciel cassé et le logiciel fixe. Et je saurais que cela n'avait pas toutes les caractéristiques des versions 8 +.
Si vous tracez les versions logicielles sur une ligne, vous penseriez à une ligne de numéro de 1 à 10. Où 7.1 correspond à cette ligne? Il tient sur le côté, comme une branche relie le tronc d'un arbre. C'est là que nous obtenons les noms de "branche" et "tronc".
Bonne somme, mais très rcs / cvs orientés. Contrairement aux CV, des systèmes tels que Subversion et Git donnent des identifiants uniques à chaque commit. Cela signifie que vous ne vérifiez pas la version 1.10 de Foo.c, vous vérifiez FOO.c à partir de la version 12345 du référentiel. Même idée, mais il supprime la nécessité de marquer n'importe quoi "Version 7" pour toute autre raison que de commodité.
1) Par exemple, comme décrit, j'ai a mis la première version en VC. Puis Je supprime tous les fichiers et les réécrire un nouveau. Si j'ai bien compris, ça serait Soyez une nouvelle "branche", non?
Vous avez raison de penser qu'une réécriture doit être traitée comme une nouvelle branche, mais vous devrez indiquer votre système de contrôle de version que vous créez une nouvelle branche.
2) Si je continue à développer que Version, je vais juste continuer à prendre à cette "branche"?
oui.
3) fait économiser VC, lors de l'enregistrement d'un Sauvegarder-point dans une branche, tous les fichiers dans, ou fait-il juste sauver la différence entre eux?
Je pense que la plupart des systèmes de contrôle de la version stockent les Deltas entre les révisions au lieu de l'ensemble des fichiers afin de conserver l'espace disque.
4) Puis-je facilement obtenir tout (entier Projet) Dossiers d'un certain Enregistrer-point dans une branche ou ai-je Pour le suivre à travers Diff's jusqu'à le début ? (Je veux juste être capable de dire: "Ici, c'est le Enregistrer-point - copiez tous les fichiers dont vous avez besoin Il ressemble donc à ceci ")
La plupart des systèmes de contrôle de la version vous permettront de vérifier toute révision.
5) Qu'est-ce que cela signifie, dans très Simples termes, pour "pousser" et "tirer". je Ne comprend pas la différence entre "push" / "tirer" et "commit".
Les systèmes de contrôle de version distribués ont des commandes "Push" et "Tirez" pour télécharger ou télécharger des modifications sur un serveur distant et la commande "commit" pour enregistrer les modifications apportées au référentiel local. Cela contraste avec SVN, qui stocke uniquement les informations de révision du côté serveur, donc avec SVN, vous "commettez" sur le serveur distant.
Je crois que vous trouverez une perspicacité ceci: Un guide illustré sur GIT sur Windows .
Je vais essayer de répondre à vos questions à son tour.
1) Par exemple, comme décrit, j'ai a mis la première version en VC. Puis Je supprime tous les fichiers et les réécrire un nouveau. Si j'ai bien compris, ça serait Soyez une nouvelle "branche", non?
Suppression des fichiers et la réécriture de zéro n'est pas la marque d'une branche. Pensez à un tronc et à une branche. Un modèle commun est de conserver le code pour le développement en cours (le plus récent et le plus grand) dans le coffre. Ensuite, à un moment donné, vous voudrez libérer votre code à quelle heure vous allez prendre une prise de vue du coffre. Ce coup de pression est la branche.
2) Si je continue à développer que Version, je vais juste continuer à prendre à cette "branche"?
Oui, vous pouvez continuer à développer le code dans le coffre et le code dans la branche de manière indépendante.
3) fait économiser VC, lors de l'enregistrement d'un Sauvegarder-point dans une branche, tous les fichiers dans, ou fait-il juste sauver la différence entre eux?
De votre point de vue, pensez simplement à la branche comme un tirant-pression, pas comme une séquence de diffs. En interne, différents produits mettent en œuvre les branches de différentes manières, mais vous n'avez pas besoin de vous préoccuper de cela.
4) Puis-je facilement obtenir tout (entier Projet) Dossiers d'un certain Enregistrer-point dans une branche ou ai-je Pour le suivre à travers Diff's jusqu'à le début ? (Je veux juste être capable de dire: "Ici, c'est le Enregistrer-point - copiez tous les fichiers dont vous avez besoin Il ressemble donc à ceci ")
Rétablir, pensez à une branche en tant que tir Snap-Shot de fichiers.
5) Qu'est-ce que cela signifie, dans très Simples termes, pour "pousser" et "tirer". je Ne comprend pas la différence entre "push" / "tirer" et "commit".
Systèmes tels que CSCS, CVS, SVN, Perforce, ClearCase Maintenir un référentiel central pour les actifs. Les utilisateurs poussent leurs copies locales dans le référentiel. Dans svn, cela est fait en utilisant "SVN COMMIT". Des systèmes tels que Git et Mercurial maintiennent un référentiel distribué d'actifs et l'utilisateur tire des fichiers d'autres référentiels pour mettre à jour leur propre référentiel.
1) Les branches sont entièrement sous votre contrôle, le système SC ne vous surprendra pas avec eux (à l'exception des multiples têtes dans des sytems distribués, mais votre exemple ne doit pas causer cela.) Maintenant, si vous faites une réorganisation majeure, Vous pouvez choisir de créer une nouvelle branche afin que vous puissiez les garder facilement séparé, mais c'est votre choix.
2) Si vous choisissez d'utiliser des succursales, vous pouvez continuer à développer celui que vous aimez. Tant que les changements YOUT sont engagés, vous avez votre point de contrôle et pouvez vous déplacer entre eux librement. Dans certains cas, vous pouvez même partager des changements entre eux, mais je ne vais pas entrer dans ce droit.
3 et 4) La plupart des systèmes permettront d'économiser des différences comme une économie spatiale, mais il s'agit d'un détail de mise en œuvre. Vous pouvez récupérer n'importe quelle version à tout moment, exactement comme il a été commis.
5) commettre définit un point de contrôle que vous pouvez revenir ultérieurement. appuyez sur et Tirez Reportez-vous au partage des modifications entre vous et un autre serveur ou référentiel; PUSH EST VOUS ENVOYEZ DES CHANGEMENTS QUELQUES APPAREILLE, TRAIS télécharge le travail de quelqu'un d'autre. Les systèmes centralisés tels que Subversion impliquent une poussée avec commit et vous exigent que vous soyez à jour avec des «tirages». Les systèmes distribués permettent (et exigent) que vous puissiez faire chaque partie séparément.
Je pense que vous (et quiconque ne comprend pas tout à fait que le contrôle de la version) devrait lire Eric Sins Articles sur le sujet.
Ces articles sont loin et éloignent la meilleure introduction au contrôle de la version que j'ai vu, fortement recommandé.
Je recommanderais fortement contre Git, Mercurial, etc. (Contrôle de la version distribuée) Si vous êtes le seul à travailler sur quelque chose. Vous obtenez toute la complication sans aucun des avantages.
Parfois, j'aimerais pouvoir télécharger des commentaires.
Pour élaborer sur ce qui précède, il n'y a rien de mal à utiliser un DVC comme Git ou Mercurial dans une situation mono-utilisateur travaillant sur un seul projet dans un seul répertoire. Il n'y a pas de "complication" supplémentaire si vous ne l'utilisez pas, et ces systèmes sont à la pointe de la technologie dans la version de la version qui vous obtient toutes les dernières fonctionnalités.