Se fossi in me, avrei appena impostato il progetto "OurLibrary" come qualsiasi altro. Ad esempio, come un singolo progetto che include test.

Non vedo come l'esposizione dei test di un progetto ad altri progetti sarebbe mai problematica: poiché i test fanno parte della documentazione, direi che sarebbe una buona cosa!

Se per qualche motivo veramente non è possibile, un'altra opzione da considerare è che i progetti utilizzano una versione compilata di "OurLibrary". Questo ha alcuni inconvenienti propri - ad es. dovendo gestire la versione compilata della libreria; non essere in grado di modificare il progetto di codice 'OurLibrary' direttamente da altri progetti; ecc.

L'ultimo resort

Considera che i sub-repos sono considerati una funzionalità di last resort .

Questo significa in sostanza che non devi utilizzare i repository secondari a meno che tu non abbia una ragione legittima, hai una ragione legittima, quindi fallo.

Quando poi?

Ho alcune regole empiriche per i sottorepos, quindi li uso se e solo se:

• Ho già il sottorepo come repository stand-alone (ovvero non è una libreria che posso incubare) AND
• (È il codice che possiedo O il codice nel sub-repos è attivamente sviluppato) AND
• L'aggiornamento del codice non è banale AND
• (Esiste la potenziale situazione in cui potrei voler modificare il codice del subrepo e spingerlo indietro OPPURE inserire il codice del subrepo con un nuovo specifico del progetto pur essendo in grado di estrarre e integrare le ultime modifiche in quel repository (mantiene le cose flessibili nelle emergenze e nelle scadenze)).

Ultima ragione ...

Gestione della configurazione : quando voglio monitorare quali versioni di cosa coesistono con quali versioni di qualunque cosa e, cosa più importante, voglio avere il controllo di questi.

Ad esempio, supponi di voler testare il tuo ultimo sviluppo / ramo sperimentale di "OurLibrary" rispetto al tuo codice di produzione del tuo progetto attuale. Avere sottorepos in questa situazione è molto utile.

Continua a interrogarti

Potresti sentirti a tuo agio con l'idea di usare i subrepos. Non farlo. Continuate a chiedervi "quando non dovrei usare i sottorepos?", Se non vieni con una buona ragione non usarli e tutto andrà bene.

Relax

Supponete di non aver usato i sottorepos e di aver realizzato che dovreste avere perché la ragione X: potete sempre aggiustarla in seguito, in ogni caso, non è necessaria la cronologia del sottoreport per il vostro progetto corrente.

In un caso estremo in cui si desidera rimuovere i file in cui si supponeva che il sottorepo fosse dal giorno 0, utilizzare < strong> ConvertExtension per estrarre il sottorepo con un file di mappa.

Non lo consiglierei per il tuo caso (dove il tuo progetto principale è il genitore del tuo subrepo desiderato) ma sarà utile per il caso di utilizzo della gestione della configurazione in cui avrai un nuovo repository padre per gestire le versioni tra i componenti e il tuo progetto principale è uno di questi (allo stesso livello del sottorepo desiderato), ad esempio:

project (repo)
|-component1
|-component2
|-component3

Trasforma in

project (new-repo)
|-component1 (subrepo)
|-component2 (subrepo)
|-component3 (subrepo)

Altrimenti con:

project (repo)
|-app
|-lib
|--|-libA
|--|-libB

Trasformarsi in

project (repo)
|-app
|-lib
|--|-libA (subrepo)
|--|-libB

Si lascerà un buco nella cronologia in cui la libA non esiste finché non si crea la voce .hgsub.