Scope

Scope memorizza i componenti ei relativi metadati compressi nel filesystem come "oggetto". Un ambito può essere locale, accanto all'area di lavoro, salvato nella directory .git/bit / .bit . Oppure può essere su un telecomando, che viene creato da bit init --bare .

Per eseguire il push/pull di oggetti dal telecomando, utilizzare bit export , bit import e bit fetch . Per visualizzare l'elenco dei componenti nell'ambito, utilizzare bit list oi comandi bit cat-scope di basso livello .

Quando si importano componenti in un ambito,normalmente Bit porta tutte le sue dipendenze appiattite,cioè le dipendenze dirette e le loro dipendenze ricorsive.Inoltre,durante il processo di esportazione,una volta che un componente viene spinto in un ambito remoto,Bit importa tutte le dipendenze appiattite mancanti di quel componente.Questo protegge l'utente nel caso in cui una delle dipendenze indirette sia stata cancellata o il suo ambito sia stato ridotto (lo storico caso "pad-left").

Objects

  • Component e : contiene i dati principali sul componente, come nome, nome dell'ambito, hash principale e un elenco di tag: hash.
  • Version e - rappresenta un gioco da ragazzi. ha gli hash del file di origine, i dati delle dipendenze, i dati di build, ecc.
  • Source - file-sorgente/file-dist
  • Lane - ID dei componenti e loro teste della corsia

Export Process

La sfida principale nel processo di esportazione è quella di mantenere gli ambiti coerenti quando si esporta in più ambiti.un utente può esportare componenti appartenenti a ambiti diversi con dipendenze di ciclo tra di essi.Ad esempio,lo scopeA/compA dipende dallo scopeB/compB che dipende dallo scopeA/compA.Se si persistono i dati di scopeA/compA ma si fallisce durante la persistenza di scopeB/compA,gli utenti che importano compA otterranno un componente non valido,poiché la sua dipendenza compB è mancante.

Poiché Bit è distribuito,non c'è un luogo centrale in cui far persistere tutti gli ambiti in una volta sola.Ciò richiede alcuni passaggi aggiuntivi per garantire l'integrità dei dati.

Durante l'esportazione vengono eseguite le seguenti fasi:

  1. trasferimento dati: i componenti vengono esportati nei diversi ambiti e archiviati in una directory temporanea pending-object/<export-id> sul telecomando. Questo è un passaggio non bloccante, il che significa che più client possono accedere a questo passaggio contemporaneamente.
  2. validation: verifica che gli oggetti possano essere uniti senza errori come merge-conflict o component-needs-update. È qui che inizia il "blocco". se sono presenti più export-id, solo il primo può accedere a questo passaggio, il resto ottiene un'eccezione ServerIsBusy . Il motivo del blocco è che se due client esportano contemporaneamente e convalidano contemporaneamente sullo stesso componente, poiché convalidano rispetto al componente archiviato, entrambi possono avere esito positivo ma dopo aver salvato uno di essi, l'altro otterrebbe un errore di conflitto durante il persistere, che vogliamo evitare a tutti i costi. Nel caso in cui qualcosa vada storto in questo passaggio, l'oggetto in sospeso di questo export-id viene eliminato per tutti gli ambiti per rilasciare le risorse.
  3. persist - carica i dati dagli oggetti in sospeso e salvali negli oggetti, i componenti e le corsie vengono uniti con cura per non perdere alcun dato locale. Se la persistenza di un ambito è stata completata correttamente, elimina la directory dell'oggetto in sospeso per liberare la risorsa. Se non riesce, gli oggetti in sospeso non vengono eliminati, quindi nessun'altra esportazione potrebbe eseguire il push dei dati fino al completamento di questa esportazione. Per poter riprendere questa persistenza non riuscita, l'utente può rieseguire l'esportazione con il --resume <export-id> . Per assicurarsi che gli ambiti non siano bloccati per sempre nel caso in cui l'utente che ha eseguito l'esportazione non sia disponibile, un bit resume-export <export-id> <remotes...> può essere in esecuzione al di fuori dell'area di lavoro originale.
  4. import-missing-dependencies-come descritto sopra nella sezione "scope",serve a verificare che lo scope remoto abbia tutte le dipendenze appiattite dei componenti esportati.In caso di errore in questo passaggio,il processo continua e l'esportazione non viene annullata.

Una volta completati tutti i passaggi, Bit aggiorna il file .bitmap con le nuove versioni e gli oggetti, se necessario. I dati trasferiti al server sono minimi, poiché Bit salva gli hash taggati/snappati localmente, sa esportare solo quelli. Per ignorare questo ed esportare tutti i tag/snap di un componente, usa --all-versions flag.

Import Process

TBD. Vedi #3656 per le nuove modifiche qui.