source code file system layout for 2 very similar projects (with git)

Question

we're working on "two" android apps that are very similar; in fact, they're the same apps with different graphics and color schemes, slightly different configuration and one or two unique activities that are not in the other project - but the functionality is 95% the same.

the plan was to work on one app until it is as complete as possible and then change the images and the other /res(ource) files.

of course it's not that easy; we're still working on the shared code, and patching the same code in different projects (or repositories) is - in my opinion - out of the question.

we're all using git and eclipse.

is there the "definitive guide" about handling such a situation?

my thoughts about it:

three repositories

rep1 for the unique files of application1, rep2 for the unique files of application2, and rep3 for the shared files.

if there is a way to push files in one folder (the project folder) to different repositories ... i mean, cloning rep1 automatically pulls the files from rep1 AND rep3, and pushing automatically pushes files back into to the right rep?

my teammates are suspicious; no one of us knows git very well and we're afraid of spending too much time repairing our dcvs mistakes.

2 repositories

if the first option isn't possible, our plan was to have 2 repositories. rep1 for the complete app1 and rep2 only for the rep2-specific files. a build script would replace the files from app1 with those of app2. imo this is an "accidental overwrite" minefield, and i don't like it. but as long as we don't have a better solution, this is the way to go.

eclipse

maybe there is some kind of eclipse-specific hack that would make this painless?

(edit) branching!?

i don't have any experience with branching. but this be a possible solution?

note: these are android projects; android demands a specific file layout. e.g. the name and structure of the "res" folder is pretty much fixed. this means that there are directories which contain files both app-dependent and shared files. i don't know if git can handle this.

• Jan Hudec: Branches (and the 2/3 repositories really means branches—you don't push files, you push branches) are great tool for temporary divergence and great tool for bugfixes to stable releases while working on next one, but they are totally unusable for maintaining long term similar but not equal versions. #ifdef is time proven method for that; too bad Java chose not to support it.
• Paul Draper: @JanHudec, #ifdef can be replaced by better less hacky things. The only really compelling reason to have it is for compiler/platform madness, which Java doesn't have.
• Jan Hudec: @PaulDraper: Java doesn't have as much platform differences (Android being a case in the point), but if you have 30 customers and need to ship slightly different version to each, Java changes nothing in the picture and the lack of conditional compilation is now a pain. Note that C# does have conditional compilation for exactly this reason.
• Jan Hudec: @PaulDraper: A lot can be done by having different subclasses for use in the different variants and I am all for it, but in practice there are cases that are difficult to handle that way or the extra inheritance makes things less readable in the end.
• Paul Draper: @JanHudec, "in practice...makes things less readable in the end". Agreed. That a pretty good summary of Java ;)

Answer 1

we solved the problem - it's actually trivial, and we had the answer for months, only we didn't recognize it as such:

• 2 android projects
• 1 android project as a library

3 directories, all in the same git rep. so easy.

edit: actually, i've been a bit overenthusiastic with this answer. there are still unsolved problems with resource sharing (libraries taking resources from host projects? afaik not possible). we have devised two workarounds for that problem, but neither one is very satisfying.

late edit:

libraries actually do inherit their parents resources. so, if there is a resource string/foo = "bar" in the library project, and a resource string/foo = "boo" in the client project, then if you use string/foo in the client project the value is boo. this is a working solution, even though i have the feeling that sometimes there could be unintended namespace collisions.

• Rommudoh: that's what i had in mind after starting to read your question ;) i would have made three repos, but that's a minor detail.

Answer 2

There are two approaches you could take: 1> Maintain one code base. The code uses a parameter/config file (like app.confg in .net) to determine which which behaviors/colors/images to use at either run time or during build/compile

2> I've not used GIT, but if it like PVCS or (if you dare!) VSS, you could attach a labels to the configuration items that float with the current version and states which 'build' the item refers to. When it is time to work on application A, get where label = A, for application B, get when label = B. You need to be careful with that approach, particularly if you the applications begin to diverge or branch.