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.
>
Received on 2014-01-02 23:47:38 CET