fossile:aggiungi file al repository esistente, devo prima aprirlo?

StackOverflow https://stackoverflow.com//questions/22051797

  •  21-12-2019
  •  | 
  •  

Domanda

Desidero controllare le versioni di una directory, chiamiamolo "progetto" e manteniamo i file fossili all'interno di un'altra directory denominata "fossili". Ho creato correttamente il repository "Project.fsl", ho aggiunto i miei file di progetto, impegnato e chiuso.Il mio problema è capire come fare il passo successivo.

Ecco cosa faccio, seguendo il fossilbook suggerimenti.

$ cd project
$ fossil new ../fossils/project.fsl
$ fossil open ../fossils/project.fsl
$ fossil add .
$ fossil ci -m "first commit"
$ fossil close project.fsl

Ora ho lavorato al mio progetto, modificato alcuni file, cancellato alcuni file, creato alcuni file, rinominato alcuni file.Vorrei aggiungere lo stato attuale del progetto al repository.Come lo faccio?

In base a ciò che ho letto nel documento, avevo l'impressione di dover prima aprire il repository, quindi aggiungere file e quindi eseguire il commit.Se non apro il repository, ottengo il file Not within an open checkout. Messaggio.Ma se io open fossil vuole sovrascrivere la mia directory con i file più vecchi.(E se apro dall'interno del fossils directory, ottengo una versione "unpacked" del mio progetto copiata nella directory fossils, non quella che desidero)

$ cd project
$ fossil open ../fossils/project.fsl

Qui fossil vuole sovrascrivere il mio progetto con la versione precedente.Dico no ad ogni suggerimento.io sospetto opennon era l'approccio corretto, ma in caso contrario quale sarebbe?

Voglio aggiungere le mie modifiche al repository, quindi ora project.fsl lo è open, provo questo:

$ fossil add .
 ADDED  Slides/tmp.tex

$ fossil commit -m "no idea what I'm doing, this will not end well"
 would fork.  "update" first or use --allow-fork.

$ fossil close
 there are unsaved changes in the current checkout

A questo punto elimino tutti i file nascosti denominati .fslckout .fossil e riprovare, con risultati altrettanto deludenti.

Ad essere sincero, il mio unico interesse è fossil sta mantenendo una cronologia del mio progetto.Non ho coautori e non ho intenzione di farlo fossil diff O fossil ui o qualcosa del genere fino al momento, che spero non accada mai, in cui avrò bisogno di scavare nella storia del mio progetto.

Modificare. Sono un principiante totale.Non sono sicuro di capirne il significato checkout, manifest, leaf, eccetera.quindi è molto difficile per me ricavare qualcosa dal manuale, nonostante le innumerevoli ore trascorse a provarci.Non capisco molto di questa pagina fossil open: http://fossil-scm.org/fossil/help/open

È stato utile?

Soluzione

fossil open È la cosa giusta da fare.Nel tuo caso, è il fossil close non era necessario.

A questo punto dovresti farlo fossil open ../fossils/project.fsl --keep per aprire il repository mantenendo tutte le modifiche.

IL aprire Il comando contrassegna la directory corrente come a directory di lavoro (in termini fossili, a guardare).Ti consiglio di non chiuderlo finché non avrai bisogno di spostare il tuo repository o la directory di lavoro stessa.Personalmente, ciò accade solo quando passo a un altro computer.

Per fare in modo che i fossili identifichino tutti i cambiamenti, basta farlo fossil addremove;fossil aggiungerà quindi tutti i nuovi file e rimuoverà tutti i file eliminati, in modo che il repository corrisponda ancora una volta alla directory di lavoro.Naturalmente, dovrai comunque confermare le modifiche in seguito.

Nota Quello addremove fa non riconoscere automaticamente i nomi dei file!Se hai rinominato dei file, dovresti comunicarlo a Fossil per ogni file utilizzando l'estensione fossil rename comando, Prima esegui il addremove comando.Naturalmente, se non ti dispiace interrompere la cronologia delle modifiche di file specifici, sei libero di saltarlo e lasciare che fossil pensi che un file sia stato eliminato e invece ne sia stato aggiunto un altro.

Altri suggerimenti

Cerimonia a bassa cerimonia e facile inizio

Per un singolo sviluppatore, il ciclo di vita di un repository fossile può essere molto semplice:

    .
  1. fossil new per creare il file del repository stesso.
  2. fossil open per creare il primo (o possibilmente solo) spazio di lavoro attivo
  3. fossil add, fossil remove, fossil rename e fossil addremove per mantenere il fossile informato su quali file da tracciare.
  4. fossil commit per commettere modifiche al repository

    5. Dove vengono ripetuti i passaggi 3 e 4 come necessario attraverso la durata del progetto.

    Questo è uno dei più forti vantaggi di Fossil: è una cerimonia molto bassa dal design. È possibile mantenere un progetto molto elaborato da solo e utilizzare davvero solo fossil commit su base regolare.

    Prossimi passaggi

    La prossima fase della sofisticazione può muoversi in diverse direzioni. Se vuoi condividere il lavoro su un progetto con un secondo sviluppatore, vorrai saperne di più sulla clonazione di un repository e di sincronizzare gli aggiornamenti. Se si desidera consentire il lavoro indipendente su una funzione senza rompere le build del bagagliaio, puoi saperne di più sulla ramificazione e la fusione. Se si desidera sfruttare le funzionalità Wiki e Ticket Tracker, vorrai apprendere su fossil ui, fossil server o configurare il tuo server Web per avviare fossili.

    Ma nessuno di questi casi d'uso richiede l'uso del comando fossil close. Infatti, l'output di fossil help è stato recentemente diviso in un elenco più breve di comandi necessari per la maggior parte degli utenti e un elenco più lungo di tutti i comandi. In quella divisione fossil close non ha fatto la lista breve. Le uniche funzioni che esegue che non possono essere facilmente eseguite da una semplice eliminazione dei file è verificare che non siano modificate non salvate e per rimuovere il checkout aperto dal tuo elenco personale di checkout disponibili al comando fossil all.

    Vocabolario specifico fossile

    Anche un singolo sviluppatore vorrà imparare parte del vocabolario utilizzato dalla documentazione di Fossil.

      .
    • "Checkin": un set specifico di revisioni di file, identificato da un UUID e possibilmente da uno o più tag.
    • "Checkout": un albero di cartella associato (da fossil open) con un repository specifico. La maggior parte dei comandi fossili richiede che la directory corrente sia all'interno di un checkout aperto.
    • "uuid": un identificativo univoco per qualsiasi cosa specifica memorizzata nel repository fossile. In pratica, l'UUID è lo SHA-1 ha la cosa espressa in esagono. Nella maggior parte dei casi, l'UUID può essere abbreviato a sufficienti cifre principali del pieno hash per identificarlo in modo univoco. Di solito verrà scritto come 8 o 10 cifre in parentesi quadre.
    • "artefatto": un file o o altri contenuti (una pagina wiki, un biglietto, un manifesto, ecc.) memorizzato nel repository. Ogni file che fai il check-in diventa un artefatto. Così fa tutti i metadati (commenti, timestamp, ecc.) Circa ogni checkin.
    • "ramo": una linea di controlli successivi che si incorniciano da un check-in root. I rami vengono utilizzati per tenere da parte le modifiche a parte fino a quando non sono pronti per essere fusi, o semplicemente per contenere modifiche che sono errori.
    • "foglia": il check-in alla fine di un ramo.
    • "tronco": il primo ramo in qualsiasi repository è denominato "tronco". La maggior parte degli altri rami sarà rami da un controllo lungo il bagagliaio.
    • "manifest": l'elenco dei file modificati in un particolare controllo insieme ai metadati che descrivono quel check-in (l'utente, il tempo, la descrizione, l'UUID del suo controllo genitore e qualsiasi tag potrebbe trasportare) costituisce il manifest . La maggior parte degli utenti non ha davvero bisogno di preoccuparsi dei manifesti, vengono creati da fossil commit e possono essere visualizzati dall'interfaccia Web.

    Interfaccia Web

    Qualsiasi utente vorrà apprendere sull'interfaccia web su fossile. Un facile passo facile è dire fossil ui all'interno di un checkout aperto. La timeline mostra la cronologia dello sviluppo con un nodo per ogni controllo e linee disegnate per mostrare ramificazione e fusione. L'interfaccia Web è altamente configurabile, fornisce un wiki e un biglietto e fornisce anche una GUI da cui è possibile regolare la maggior parte delle impostazioni relative al progetto e al repository.

    Fossil stesso è un server web efficiente per il contenuto del repository. Infatti, la maggior parte delle pagine di Il sito ufficiale del fossili è servito da fossili stesso dal repository per il codice sorgente a fossile.

    Fonti per ulteriori informazioni

    A parte il sito Web e la guida del comando individuale disponibile da fossil help, ci sono molte altre risorse che molti Gli utenti dovrebbero essere a conoscenza.

    C'è il Elenco utenti fossili con rapporto comodamente elevato al raggio di rumore. Gli sviluppatori chiave prestano attenzione ad esso, così come molti utili e kn

Utenti a owledgeabili. L'elenco ha almeno un Archivio , così come Un elenco separato per gli sviluppatori per discutere nuove funzionalità e piani, ma il fossile-dev non sarà interessante a meno che tu non voglia lavorare sugli interni di fossili.

Jim Schimpf ha un libro che tenta di essere sia un tutorial e completo Riferimento e include alcuni consigli sulle migliori pratiche. Vale la pena una lettura.

L'aiuto della riga di comando incorporata insieme alla documentazione per tutti gli URL della pagina compresa dall'interfaccia Web è disponibile anche dall'interfaccia Web di Fossil presso il /help URL all'interno del sito di qualsiasi repository. Quel testo della guida include la documentazione di ogni comando, compresi i comandi di prova interna non supportati.

E infine, il [tag fossile] [tag] qui a Stackoverflow non può essere ignorato come risorsa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top