Emulating SDLC levels under /branches without causing conflicts.

brian_bennett
brian_bennett
We are attempting to emulate the idea of SDLC levels with our Subversion and track at what SDLC "level" any particular set of changes is currently in. So a common (empty) repository will look like:  branches branches/DEV branches/MODEL branches/MODEL/trunk  tags trunk  /trunk is created first and then /trunk is copied to /branches/MODEL/trunk. /branches/DEV represents an area where developers work on changes in isolation and merge to /branches/MODEL/trunk when ready (which represents Model Office.) When source changes are made, the following steps are used: 1. /trunk is copied to /branches/DEV/chgxxx where chgxxx is some project, sprint, etc. tracking number. Changes are made and committed back to /branches/DEV/chgxxx. 2. The changes in /branches/DEV/chgxxx are then merged into /branches/MODEL/trunk. Testers can now export a copy of /branches/MODEL/trunk to a testing area and be assured they have all changes present in /branches/MODEL/trunk. And to give users an indicator of what SDLC level any change is currently at, /branches/DEV/chgxxx is moved to /branches/MODEL/chgxxx. 3. Next the changes in /branches/DEV/chgxxx are merged into /trunk and /branches/DEV/chgxxx is deleted.  This model is causing conflicts under the following conditions however: 1. /trunk is copied to /branches/DEV/chgxxx, Newfile1.txt is added and committed back to /branches/DEV/chgxxx. 2. /branches/DEV/chgxxx is merged into /branches/MODEL/trunk and /branches/DEV/chgxxx is moved to /branches/MODEL/chgxxx. 3. /branches/MODEL/chgxxx is merged into /trunk and /branches/MODEL/chgxxx is deleted. 4. /trunk is copied to /branches/DEV/chgyyy, Newfile2.txt is added and committed back to /branches/DEV/chgxxx. 5. When we attempt to merge /branches/DEV/chgyyy into /branches/MODEL/trunk, we get a tree conflict error on Newfile1.txt.  If we stop after step #3 above and try a merge from /branches/MODEL/trunk into a working copy of /trunk, we can see the tree conflict on Newfile1.txt at that point.  Is there a way we can make this model work?  We know from testing that we can make this model work by modifying step #3 above so that /branches/MODEL/trunk is merged into /trunk. Our concern is that we would lose the ability to be able to easily merge individual changes from /branches/MODEL to /trunk. In other words, consider this use case: 1. DeveloperA copies /trunk to /branches/DEV/chgxxx, makes modifications, commits the changes, then merges /branches/DEV/chgxxx into /branches/MODEL/trunk and then deletes /branches/DEV/chgxxx. 2. DeveloperB has an "emergency" fix they need to make so they copy /trunk to /branches/DEV/chgyyy, makes modifications, commits the changes, then merges /branches/DEV/chgxxx into /branches/MODEL/trunk and then deletes /branches/DEV/chgyyy. 3. Assume that changes from chgxxx cannot be moved to /trunk yet, but the changes from chgyyy must be merged immediately. If we were forced to merge /branches/MODEL/trunk into /trunk, then changes from chgxxx would be moved to /trunk. How would a merge like this use case need to be handled? Would we need to specify individual revision numbers to merge?

Last updated

DougR
DougR
Brian: I don't have the time to comment in detail right now. However, I think you need to be aware of https://issues.apache.org/jira/browse/SVN-4669 - since with this amount of sub-tree merging going on I suspect that your merges might get impossibly long over time (unless the bug is fixed).

1-2 of 2

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.