#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2006
    Posts
    7
    Rep Power
    0

    Multiple sourcecode for one project.


    I have a project, let's call it A, that has been through 2 major releases since I've been with the company.
    So Project A has major Release 1 and Release 2.
    Right now I have one source code for both releases. So, if I do a fix it'll do both releases. The concern is that I could break Release 1 if I do a fix for Release 2.

    This is an old VB6 project. However if it wasn't then I'd have to create a unit test for each fix for both releases?

    Even though I'm forced into splitting my source code for each version now. Which means I have to maintain all versions for a fix. So, if I fix release2 then I have to go into release1 and make the change as well. I can see this going on for a couple years because we'll support both those versions, maybe even a Release 3, until Release 1 is out-of-scope.

    I just want to know the correct way this should be done or how the general Software Practices are handling out there.

    Thanks a bunch for your responses.
  2. #2
  3. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    What version control software are you using? Ideally it should allow you to:
    - have a separate branch for each release, plus the master branch (the most recent code base for active development)
    - perform the fix on the master branch code and commit the fix to the master branch
    - merge that commit into both release branches
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2006
    Posts
    7
    Rep Power
    0
    Thanks for the reply!

    We are switching from TFS to Subversion.
    One year ago we switched from VSS to TFS.
    I can't change anything of how it's going to be done but this is how it is going to be.

    Build1 Trunk -- Past Build
    - Any fixes for this build done here
    - Snapshot for Revisions done here i.e. Build1 Revision1
    - Separate source code for this build.

    Build2 Trunk -- Current Build
    - Any fixes for this build done here
    - Snapshot for Revisions done here i.e. Build2 Revision1
    - Separate source code for this build.

    Build3 Trunk -- Future Build
    - Any fixes for this build done here
    - Snapshot for Revisions done here i.e. Build3 Revision1
    - Separate source code for this build.

    As you can see, I now have three places to update code for any fixes. Is this normal?
  6. #4
  7. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    If all three trunks are evolutions of the same source code base then no, it's not at all normal. In that situation your repository is set up incorrectly, but since you're switching to SVN you have an opportunity to fix that mistake.

    Having completely separate repositories for each build of a software project is not the correct way to set up a version control system unless each build of that software project is not based on a previous version. Since you have bug fixes that need to be implemented in all three trunks I'm assuming that all of your code is based off the same original code base.

    There are multiple correct setups for a software repository like this; one correct possibility:
    - your in-development/future major-build is at /trunk
    - your current major-build is at /branches/build2
    - your previous major-build is at /branches/build1
    - release builds (what I think you're calling revisions, but I'm not going to call them that because the word revision has a special meaning in version control terminology) can be tagged at /tags/release-1, /tags/release-2, etc.

    When it is time to release a major version, you branch the version off of trunk. Development on the next version continues on trunk, while the branched version is only used to apply fixes to that branch.

    When it's time to release a public build, simply create a new tag for that release off whatever branch you're releasing from.

    It's important to remember that a branch is essentially a fork in development, while a tag is a snapshot of a particular revision.


    So now a bug comes along.

    If the bug only exists for a particular major version, then you fix the bug in the proper branch and there is no need to share the fix.

    If the bug only exists in build1 or build2 (maybe because you refactored the code for it in build3), then checkout build2, fix the bug and commit to build2, then checkout build1 and you can merge the fix commit(s) back into build1.

    If the bug exists in all branches, then do the fix in the trunk and commit it, then checkout each branch and merge the fix commit(s) into the branch.


    With SVN it is actually possible to merge commits from different repositories, but it's not really good practice to keep the same code in multiple repositories.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around

IMN logo majestic logo threadwatch logo seochat tools logo