la logique de base de travail avec contrôle de code source à localhost + Mercurial

Question

Je suis assez nouveau à Mercurial - en fait nouveau au contrôle de code source

.

J'ai des projets à localhost, qui est ~ / MAMP / htdocs. Je veux travailler tous les locaux. Il y a un point que je suis confus au sujet:

Je devrais garder du référentiel à un autre chemin que mes htdocs je pense, donc je créé « / représentants / » le dossier et la création de dossiers pour chaque projet sous ici et copiez tous les fichiers du dossier de projet htdocs aux représentants.

  

par exemple; Projet01

     

Copie de fichiers de ~/mamp/htdocs/project01/ à   /reps/project01/

Mais je travaille à localhost (htdocs) pour changer les fichiers, etc. Comment puis-je raconterai ces changements /reps/?

Il est évident que je manque un point très évident au sujet du contrôle de source. Ai-je fait un départ mal?

Tous les tutoriels que j'ai trouvé en ligne nécessite une sorte de connaissances de base, je suppose; aucun d'eux ne dit rien de ce qui signifie zéro! : /

Answer 1

si vous souhaitez modifier vos fichiers dans ~/mamp/htdocs/project01/ (parce que je suis d'accord aussi qu'il serait bon d'avoir une sorte de zone de transit où vous pouvez tester vos modifications avant de les déployer la façon la plus simple, le serveur de production, mais peut-être est précisément votre machine qui est la zone de mise en scène, donc tout est ok alors :-)) est à:

1. Installer Mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (tout ce que vous voulez gérer)
5. hg commit -m"initial version"

Une fois que vous avez fait hg init, il y a un dépôt dans un .hg dir sous ~/mamp/htdocs/project01/! Il est impossible d'éviter ce (encore au moins) avec hg: si vous avez des sources de Projet01 vous devez avoir une prise en pension à Projet01. Et il est suffisant parce que vous pouvez bénéficier d'un contrôle de version avec juste que, chaque fois que vous modifiez un fichier, vous pouvez vous engager et donner un message de journal pour indiquer au système ce que vous avez fait, par exemple.

• <edit> a.html
• hg status (vous dira les fichiers en cours de modification)
• hg diff (vous dire les différences avec la version enregistrée)
• hg commit -m"what-has-changed-message" (enregistrer une nouvelle version)

Même si elle n'est pas nécessaire d'avoir un autre repo ailleurs (par exemple dans / représentants) si vous voulez , par exemple d'avoir vos données dans une zone Backupées, vous pourriez simplement cloner un dans $ HOME:

• cd /reps
• hg clone /home/name/mamp/htdocs/project01/ project01

Ce qui se mettra en /reps/project01 une copie exacte de ce que vous avez fait: toutes les modifications et tous vos messages de journal. Maintenant, si vous faites cela, chaque fois que vous faites "hg commit" pour enregistrer un changement dans votre repo primaire, vous devez également faire "cd /reps/project01" et "hg pull" afin de transmettre les modifications à / reps si vous le souhaitez rester synchronisé.

L'espoir est assez simple ..

Answer 2

Il y a de nombreuses approches différentes / méthodes . Voici comment je travaille:

1. Développement: Je vérifie (clone dans mercuriels cas) mes fichiers à mon 'environnement de développement' pour travailler sur les engagent alors / push / etc. au même endroit.

2. Les étapes suivantes: Une fois que je pense qu'ils sont prêts pour le test utilisateur / production / ou quel que soit votre prochaine étape est, vous pouvez distribuer votre code comme

   2a. package (pourrait être un simple zip de vos derniers fichiers) ou

   2b. vérifiez-les dans ce répertoire de l'étage suivant.

3. Autres utilisations: Une fois que vous êtes à l'aise de travailler avec les principaux scénarios d'utilisation, alors vous devriez envisager d'autres noreferrer usages de contrôle de révision comme marquage , branchement et fusion

Answer 3

Vous devriez normalement garder votre VCS (système de contrôle de version) et ses fichiers séparés de votre environnement de serveur web de production (ce qui est ce que je vous déduis demandez à propos étant donné la mention htdocs).

De nombreux (au moins) vieux temps systèmes web ont une zone de transit où vous copiez le matériel du système source, que vous pouvez vérifier soigneusement à l'aide d'une seconde (non accessible au public) serveur web. Lorsque vous êtes confiant que le code est correct, vous pouvez le déplacer dans la production.

Ce scénario a trois domaines:

• zone de travail (développement) avec VCS, etc; peut-être accessible via un autre serveur web).
• zone Mise en scène (pas VCS, pas d'accès public, les tests et validation)
.
• Zone de production (pas VCS, l'accès du public).

Il sonne un peu comme si vous amalgamant ces trois - un scénario commun dans mon expérience limitée. Même si vous décidez de le faire sans la zone de mise en scène, vous avez besoin de séparer vos systèmes de développement et de production. Et le VCS (Mercurial) est utilisé dans la zone de travail.