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:34:12 CET