la logica di base di lavoro con controllo del codice sorgente in localhost + Mercurial

Question

Sono abbastanza nuovo a Mercurial - in realtà nuovo a controllo del codice sorgente

.

Non ho progetti a localhost, che è ~ / MAMP / htdocs. Voglio lavorare tutti i locali. C'è un punto Sono confuso su:

dovrei tenere repository in un percorso diverso rispetto ai miei htdocs penso, così ho creato "/ ripetizioni /" cartella e la creazione di cartelle per ogni progetto sotto qui, e copiare tutti i file dalla cartella di progetto htdocs a ripetizioni.

  

, per esempio; project01

     

copiare i file da ~/mamp/htdocs/project01/ a   /reps/project01/

Ma io lavoro a localhost (htdocs) per la modifica dei file, ecc così come faccio applicare questi cambiamenti ai /reps/?

Ovviamente mi manca un certo punto molto evidente su controllo del codice sorgente. Ti ho fatto una partenza sbagliata?

Tutti i tutorial che ho trovato on-line richiede una sorta di base di conoscenza, credo; nessuno di loro dice nulla dal punto zero che significa! : /

Answer 1

Il modo più semplice, se si desidera modificare i file in ~/mamp/htdocs/project01/ (perché sono d'accordo anche che sarebbe bene avere un qualche tipo di area di sosta dove si poteva verificare le modifiche prima di distribuirle al server di produzione, ma forse è proprio la macchina che è l'area di sosta, in modo del tutto ok allora :-)) è quello di:

1. Installa Mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (ciò che si desidera gestire)
5. hg commit -m"initial version"

Dopo aver fatto hg init, c'è un repository in una directory .hg sotto ~/mamp/htdocs/project01/! Non è possibile evitare questo (ancora almeno) con hg: se si dispone di fonti in project01 è necessario disporre di un pronti contro termine in project01. Ed è sufficiente in quanto è possibile beneficiare di controllo di versione con solo che, ogni volta che si modifica un file, si può commettere e dare un messaggio di log per dire al sistema di ciò che avete fatto, per es.,

• <edit> a.html
• hg status (vi dirà i file attualmente modificati)
• hg diff (vi dirà le differenze con la versione salvata)
• hg commit -m"what-has-changed-message" (salvare una nuova versione)

Anche se non è necessario avere un altro repo altrove (ad esempio, in / ripetizioni) se da , per esempio, di avere i dati in una zona backuped, allora si può solo clonare il uno in $ HOME:

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

che otterrà in /reps/project01 una copia esatta di quello che hai fatto: tutte le modifiche e tutti i vostri messaggi di log. Ora, se si fa questo, ogni volta che si fa "hg commit" per salvare un cambiamento nel vostro repo primaria, è anche necessario fare "cd /reps/project01" e "hg pull" per inoltrare le modifiche / ripetizioni se si vuole rimanere sincronizzato.

La speranza è abbastanza semplice ..

Answer 2

Ci sono molti approcci diversi / metodi . Ecco come io lavoro:

1. Sviluppo: I check (clone in caso mercuriali) i miei file al mio 'ambiente di sviluppo' a lavorare su di essi poi commettono / push / etc. nello stesso luogo.

2. Tappe successive: Una volta che penso che siano pronti per i test utente / produzione / o qualunque sia la vostra prossima tappa è, allora è possibile distribuire il codice come

   2a. pacchetto (potrebbe essere un semplice zip dei tuoi file più recenti) o

   2b. check them out in quella directory fase successiva.

3. Altri Usi: Una volta che siete proprio agio lavorando con i principali scenari di utilizzo, allora si dovrebbe prendere in considerazione altri noreferrer usi di controllo di revisione, come codifica , ramificazione e la fusione

Answer 3

Si dovrebbe normalmente mantenere il VCS (sistema di controllo di versione) e le sue file separati dal proprio ambiente di web server di produzione (che è quello che deduco che stai chiedendo circa data la menzione di htdocs).

Molti sistemi web (almeno vecchio tempo) hanno una zona di sosta in cui si copia il materiale dal sistema di origine, che è possibile controllare con attenzione utilizzando un secondo (non accessibile al pubblico) del server web. Quando si è sicuri che il codice è corretto, è possibile spostarlo in produzione.

Questo scenario ha tre aree:

• di lavoro (sviluppo) zona con VCS, ecc; forse accessibile tramite un altro server web).
• area di sosta (senza VCS, senza accesso del pubblico; test e validazione)
.
• Zona di produzione (non VCS, l'accesso del pubblico).

Suona un po 'come se si sta confondendo questi tre - uno scenario comune nella mia esperienza limitata. Anche se si decide di fare a meno della zona di sosta, si ha bisogno di separare i sistemi di sviluppo e di produzione. E il VCS (Mercurial) è utilizzato nella zona di lavoro.