If you can separate out the twenty files that might be different between
the two projects - put them into a different folder for the "A"
application as well, and not just for "B" - then your process likely
gets even easier.
Then you can have the files in "B" be a straight up ongoing branch of
what's different from the changes in "A".
Create that branch by first making a copy of those 20 files from "A",
then replacing them with the versions from B & committing.
Eric.
On 1/2/14, 2:25 PM, Mike Fochtman wrote:
I'm part of a small development team (currently 4). We have two
applications used in-house that consist of about 1900 source files.
The two applications share about 1880 of the files in common, and
there are only about 20 different between them.
For a lot of complicated reasons I won't go into here, we can't split
the common files into a shared-library sort of project.
Most of our development goes on in application 'A'. Currently we then
transferred over to the other application 'B' development machine
manually and build/test that one.
I was thinking of having all the 'A' files be in the main
/application/trunk tree of the repository and then somehow have just
the 20 or so files unique to 'B' in some sort of
/application/branches/Bapp directory tree.
This means I'd have to 'switch' those 20 files, (one time only
right?), on the B-development machine so it would be a mix of mostly
/trunk and just those few files under /branches/Bapp.
This would mean that once changes made on the 'A' system are
committed, we could just go to the 'B' machine, do an update, and
build. If a change happened to be on one of the 20 files, we would
have to 'merge' that change from /trunk over into the /branches/Bapp
tree, right?? I think we can live with that.
Does this sound like it would work, or is there a better way (short of
splitting 1880 files off into some other project)??
Currently the team hasn't used any form of version control on these
applications because 'it would be too hard...' I desperately want to
get it/them under subversion without making two complete projects. I
know subversion won't 'share' files between projects and I understand
about that. But I just need a way to deal with these 20 out of 1900
files. (may even be less than that when we start actually digging into
it)
Thanks for any input.
Mike Fochtman
P.S. Not subscribed to list, so please cc to my 'from' address.
