subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <>
Subject Re: Repository Structure Question
Date Thu, 02 Jan 2014 22:47:05 GMT
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.


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.

View raw message