Skip to main content
Software Engineering

Return to Question

branching
Source Link
stefs
stefs
  • 191
  • 8

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.

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?

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.

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.

Source Link
stefs
stefs
  • 191
  • 8

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

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?

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.