layout del file system del codice sorgente per 2 progetti molto simili (con git)

Question

layout del file system del codice sorgente per 2 progetti molto simili (con git)

#1 da (4 voti)
#2 da (2 voti)

2

stiamo lavorando su "due" app Android molto simili; infatti, sono le stesse app con diverse grafiche e combinazioni di colori, una configurazione leggermente diversa e una o due attività uniche che non sono nell'altro progetto, ma la funzionalità è uguale al 95%.

il piano era di lavorare su un'app fino a quando non fosse il più completo possibile e quindi modificare le immagini e i file other / res (ource).

ovviamente non è così facile; stiamo ancora lavorando al codice condiviso e l'applicazione di patch dello stesso codice in diversi progetti (o repository) è, a mio parere, fuori discussione.

usiamo git ed eclipse.

c'è la "guida definitiva" sulla gestione di tale situazione?

i miei pensieri a riguardo:

tre repository

rep1 per i file unici di application1, rep2 per i file unici di application2 e rep3 per i file condivisi.

se c'è un modo per spingere i file in una cartella (la cartella del progetto) in diversi repository ... voglio dire, la clonazione di rep1 estrae automaticamente i file da rep1 AND rep3, e spingendo automaticamente spinge i file di nuovo nel rappresentante corretto ?

i miei compagni di squadra sono sospettosi; nessuno di noi conosce bene Git e abbiamo paura di passare troppo tempo a riparare i nostri errori di dcvs.

2 repository

se la prima opzione non è possibile, il nostro piano era di avere 2 repository. rep1 per l'app1 completa e la rep2 solo per i file specifici di rep2. uno script di compilazione sostituisce i file di app1 con quelli di app2. questo è un campo minato "di sovrascrittura accidentale" e non mi piace. ma finché non avremo una soluzione migliore, questa è la strada da percorrere.

eclipse

forse c'è qualche tipo di hack specifico per l'eclissi che renderebbe questo indolore?

(modifica) diramazione!?

Non ho alcuna esperienza con la ramificazione. ma questa è una possibile soluzione?

nota: questi sono progetti Android; Android richiede un layout di file specifico. per esempio. il nome e la struttura della cartella "res" è praticamente risolto. questo significa che ci sono directory che contengono file sia dipendenti dall'app che file condivisi. non so se git può gestirlo.

git eclipse android file-structure code-layout

posta stefs 06.10.2011 - 19:42

fonte

2 risposte

2

Ci sono due approcci che potresti adottare: 1 > Mantenere una base di codice. Il codice utilizza un parametro / file di configurazione (come app.confg in .net) per determinare quali comportamenti / colori / immagini utilizzare in fase di esecuzione o durante la compilazione / compilazione

2 > Non ho usato GIT, ma se è come PVCS o (se ne hai il coraggio!) VSS, puoi associare un'etichetta agli elementi di configurazione che galleggiano con la versione corrente e indica a quale "build" si riferisce l'oggetto. Quando è il momento di lavorare sull'applicazione A, ottenere dove label = A, per l'applicazione B, ottenere quando label = B. È necessario fare attenzione con tale approccio, in particolare se le applicazioni iniziano a divergere o diramarsi.

risposta data 07.10.2011 - 01:53

fonte

Leggi altre domande sui tag git eclipse android file-structure code-layout

Il risultato di strcmp è lo stesso su tutte le macchine e i compilatori? Organizzazione del progetto C ++ per ridurre i tempi di costruzione dei test unitari

score 4 · Accepted Answer

abbiamo risolto il problema - in realtà è banale, e abbiamo avuto la risposta per mesi, solo che non lo abbiamo riconosciuto come tale:

2 progetti Android
1 progetto Android come libreria

3 directory, tutte nella stessa versione di git. così facile.

modifica: in realtà, sono stato un po 'troppo entusiasta con questa risposta. ci sono ancora problemi irrisolti con la condivisione delle risorse (le biblioteche che prendono risorse dai progetti host non sono possibili). abbiamo escogitato due soluzioni alternative per questo problema, ma nessuno dei due è molto soddisfacente.

modifica in ritardo:

le librerie effettivamente ereditano le risorse dei loro genitori. quindi, se esiste una risorsa string/foo = "bar" nel progetto di libreria e una risorsa string/foo = "boo" nel progetto client, se si utilizza string/foo nel progetto client il valore è boo . questa è una soluzione funzionante, anche se ho la sensazione che a volte potrebbero esserci conflitti di spazio dei nomi indesiderati.