Announcement

Collapse
No announcement yet.

Emulating SDLC levels under /branches without causing conflicts.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Emulating SDLC levels under /branches without causing conflicts.

    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?

  • #2
    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).

    Comment

    Working...
    X