Help, Need help with repositories
I have a situation with my job where we have software versioning in place. We are having releases ever 2 weeks to a month. for example we are currently working on 188.8.131.52 and 184.108.40.206 we have requirements for 2.3 and 2.2.1 any changes we make to 2.2.1 need to be replicated in 2.3 also what is going on is they are going back to previous versions and making other corrections to 220.127.116.11 and now 18.104.22.168 and 22.214.171.124 and adding a new version 126.96.36.199 this is getting to be a little too much to keep up with and we have a team in china working with us also, and I am working and managing the project files. we have repositories versions for 2.3, 2.2, and 2.1 the idea is that each repository will have the latest of its sub kind well, we recently released 188.8.131.52 and then started on 184.108.40.206 and then they made a bunch of changes to 220.127.116.11 and then released the package then the chineese made changes to the files that we broke off (out of repositories) after the package was released and then stuff didn't work because the chineese wanted to replace files from 18.104.22.168 into 22.214.171.124 which may also compromise the integrity of everything. I got reprimanded for not properly communicating with the chineese to stop making changes... now, they want to have a separate repository for each an every release what is the best strategy to keep up with this. It seems like it is set up to fail and have crossover that is going to break. I have done the best I can do to keep versions of every system. am I just in over my head or what?
Hi there, The conventional way to manage projects like these would using the trunk for the latest (released) version, and using branches for development. So for example with the 2.2 project: - trunk - 126.96.36.199 -- branch for 188.8.131.52 -- branch for 184.108.40.206 Once 220.127.116.11 is ready you reintegrate it into the trunk and release it, then you can work on 18.104.22.168. This can also work for bugfixes, so that you can keep your development separate from the trunk until a bug is tested and ready for release. You can also restrict commit access to branches or the trunk to certain teams/users if you're using apache to serve your repo (though that may be more than you need at this point). There's some more info on this in the Subversion manual here: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html
1-2 of 2
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.