I trunk/rami/tag nidificati sono accettabili?

Question

In un recente progetto embedded, abbiamo utilizzato la seguente struttura svn:

project 
    branches 
    tags 
    trunk 
     electronics 
     software 
      branches 
      tags 
      trunk 

Come potete vedere, c'è un rami/tag/directory trunk nidificato per la parte software. Questo era abbastanza pratico per gli sviluppatori di software in quanto potevano semplicemente lavorare lì senza preoccuparsi del resto.

Tuttavia non sembra destra a me, potrebbe essere fonte di confusione a causa dei molteplici livelli di ramificazione, e persone che lavorano più alto nella gerarchia può essere disturbato da tutta la spazzatura che hanno da scaricare se il checkout top trunk ...

Quindi sto pensando di andare a un repository di solo trunk per il prossimo progetto, e se gli sviluppatori non vogliono il materiale non software, possono effettuare il checkout project/trunk/software e diramarlo a project/branches/br-1234/software , ecc.

Cosa ne pensi di tronchi nidificati? Pro per favore &!

Come una domanda a parte: rami/tag dovrebbero sempre essere copie del trunk (o di un altro ramo), o è accettabile creare un ramo di una sottodirectory di trunk?

Answer 1

I trunk nidificati indicano per me un insieme di codice con un ciclo di vita diverso da quello del genitore. Prenderò in considerazione questi progetti concettualmente separati. Inoltre, tieni presente che il tuo repository può avere più progetti di primo livello, il che dovrebbe ridurre il mantenimento di un repository separato per ogni progetto. Considero l'utilizzo di repository separati quando ho bisogno di una configurazione a livello di repository separata: accessibilità, protocollo di trasporto, autenticazione/autorizzazione (sebbene possano essere configurati all'interno di un repository).

main_project 
    branches 
    tags 
    trunk 
     electronics 
software 
    branches 
    tags 
    trunk 

allora si potrebbe aggiungere una cartella libs-main_project/trunk per contenere una forma compilata di software, o forse considerare l'utilizzo di un riferimento SVN esterna per puntare a software/trunk dall'interno main_project/trunk.

Inoltre "main_project" potrebbe ora essere denominato "elettronica", in tal caso rimuovere la cartella "elettronica" in "trunk".

Answer 2

Direi che non è l'ideale, si confonde molto rapidamente. Dato che in realtà non occupa molto/alcuno spazio di archiviazione per creare rami/tag, non ci sono molti motivi per finire con una struttura come questa. Ramo a livello di progetto solo IMHO.

Answer 3

Accettabile a chi? Non c'è nessun Papa di sovversione, e ogni organizzazione è libera di fare ciò che si adatta meglio. La versatilità di SVN che ti dà quella libertà è una buona cosa.

Answer 4

La risposta breve a tutte le vostre domande: no.

che sto immaginando un Abbott & Costello "chi è il primo" discussione: "ho fuso al tronco" "Quale tronco?" "il trunk del ramo di integrazione" "Quindi il trunk è aggiornato?" "Quale baule?"

I nuovi membri del team avranno difficoltà ad adattarsi a uno schema che contraddice la loro precedente esperienza. Dovranno cercare la documentazione interna o fare domande su qualcosa che dovrebbe essere davvero semplice.

Molti strumenti & Gli IDE sono molto più difficili da utilizzare se si utilizza un layout non standard.

Di maggiore preoccupazione è la seconda domanda relativa ai sottoinsiemi di branching/tagging del trunk o di un ramo. con sovvertite copie a buon mercato non c'è guadagno di spazio o tempo per ramificare/taggare un sottoinsieme - e ancora più importante il tuo svn: mergeinfo diventerà molto meno utile se le persone si diramano/tagano ovunque ma al massimo livello.