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        2.2.1.0 and 2.3.0.0        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        2.2.0.0    and now 2.1.4.1 and 2.1.5.0 and adding a new version 2.1.5.1        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 2.2.0.0 and then started on 2.2.1.0 and then they made a bunch of changes to 2.2.0.0 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 2.2.1.0 into 2.2.0.0 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?

Last updated 10 years ago

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 - 2.2.0.0 -- branch for 2.2.1.0 -- branch for 2.2.2.0   Once 2.2.1.0 is ready you reintegrate it into the trunk and release it, then you can work on 2.2.2.0.   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