> 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)
There's a couple of ways to do this. Externals might help.... it really depends on if those "20 files" are all isolated in a single folder for example. Also, you don't need spate "machines" you can have separate working copies on the same machine.
It sounds like you are saying those files are not "completely different" but there are differences from one build to the next. Also, it sounds like a VERY small portion of the overall app... due to this...
I would suggest that you use Build/compiler defines/switches with compiler directives (most languages have them) with branching logic. For example in C# you could do:
#if APPA
// changes or branching or whatever that is needed for app A
#endif
Then, your build scripts can define APPA or APPB.
This is pretty common way to include or exclude debug code... but doing it for different apps or distributions of apps is another common use.
BOb
Received on 2014-01-03 17:27:48 CET