Loading ...
Sorry, an error occurred while loading the content.
 

[XP] Re: [extremeprogramming] Parallel Version Development: Branching & Merging

Expand Messages
  • Andy Glew
    ... When I asked a similar question on the newsgroup prior to this mailing list - my question was actually about applying refactorings to code imported from,
    Message 1 of 23 , Feb 1, 2000
      > How can you possible refactor when parallel development is involved.
      >
      > My client maintains we can't refactor classes that exist in a prior released
      > version because of these head aches. It's hard to disagree. Help me out!

      When I asked a similar question on the newsgroup prior to this mailing list
      - my question was actually about applying refactorings to code imported
      from, and tracking, outside sources - the answer was pretty much
      "wrap up that code and try not to touch it". :-(

      But allow me to guess at some things that might help:

      Much of the problem is that many of our version control tools
      are file based - and class based tools are only a little bit better.
      When, e.g., a method in class A is patched, but that method has
      migrated to class B, all of the VC tools that I am familiar with will
      give up and report a conflict that has to be patched manually.

      However, there's another class of VC tools that is line based
      - Cray's old "deck of cards" based tool was like this. In the modern world,
      I'm not sure, but IBM Visual Age C++ / Java at least have the potential
      to act like this. In such a VC system, one can track the evolution of
      individual lines of code - so if a method has been moved, the VC
      system can see where it has been moved to, and take a stab at applying
      the patch.

      Please, if anyone is using Visual Age and can confirm that their code
      database provides line based VC, please tell me!

      ---

      Flip side: in typical file and class based VC systems, maybe refactoring
      makes patches harder to apply. But, at least you should be able to run the
      tests that come with the patch? Especially if you move methods,
      but leave the old method around delegating.
    • Ron Jeffries
      ... There s truth to this notion. What you can do is limited by what s published. Much refactoring doesn t impact the public API, and you can do that with
      Message 2 of 23 , Feb 2, 2000
        At 10:31 PM 2/1/2000 -0500, you wrote:
        >My client maintains we can't refactor classes that exist in a prior released
        >version because of these head aches. It's hard to disagree. Help me out!

        There's truth to this notion. What you can do is limited by what's
        published. Much refactoring doesn't impact the public API, and you can do
        that with impunity. (The customer does have to load a consistent cut of the
        software, of course).

        Your tests can allow you to refactor where otherwise you might fear to
        tread. But the cost of change DOES jump up after publication. Only
        experience in the specific case will tell you whether it has jumped too high.

        Ron Jeffries
        Extreme Programming Training and Consultation
        www.XProgramming.com
      • Ron Jeffries
        ... Doctor, it hurts when I fork my versions ... Doctor, it hurts when I release bugs ... However, when you do, you do. So make fixing the problem identify the
        Message 3 of 23 , Feb 2, 2000
          At 10:31 PM 2/1/2000 -0500, you wrote:
          >How can you possible refactor when parallel development is involved. Doesn't
          >this make it very difficult to promote a maintenance change (bug fix or
          >perhaps enhancement) to a class in a newer version when that new class has
          >been totally blown to bits (because of refactoring) in the new version?

          Doctor, it hurts when I fork my versions ...

          Doctor, it hurts when I release bugs ...

          However, when you do, you do. So make fixing the problem identify the
          problem in all versions, fixing it independently. Promote the Test Showing
          the Defect to all versions to prevent recurrence. Fixing the structure of
          the code is more important than added difficulty with testing/fixing. But
          if you are doing Unit Tests at 100% ab initio, the testing/fixing really
          will be cut way down.

          Ron Jeffries
          Extreme Programming Training and Consultation
          www.XProgramming.com
        • jorg.schaible@db.com
          Hi Berry, you may have a look at Perforce (http://www.perforce.com). The product is only available via the web, but it seems to fit perfectly your needs. You
          Message 4 of 23 , Feb 2, 2000
            Hi Berry,

            you may have a look at Perforce (http://www.perforce.com). The product is only
            available via the web, but it seems to fit perfectly your needs. You may have an
            impression of the product yourself (free two user version and you'll always get
            a 30 day evaluation license with any user number), have a look at a lot of "best
            strategies" material and from my experience I can only credit Perfroce's
            support.

            Regards,
            Jörg Schaible


            ---------------------------------------- Message History
            ----------------------------------------


            From: bgervin@... on 01/02/2000 18:58

            Please respond to extremeprogramming@egroups.com

            To: extremeprogramming@egroups.com
            cc:
            Subject: [extremeprogramming] Parallel Version Development: Branching & Merging
          • Ruben Reifenberg
            Well, the problem did surely not come up with XP. Whenever we refactored (also before knowing the terms refactoring and XP ) we had the problem to promote
            Message 5 of 23 , Feb 2, 2000
              Well, the problem did surely not come up with XP. Whenever we
              refactored (also before knowing the terms "refactoring" and "XP") we
              had the problem to promote fixes to later versions that were refactored.

              So I'm also generally interested in ideas how to manage it most
              efficiently...currently I try to focus on the benefits of refactoring
              and hope there are some advantages remaining also with the
              "promote-fixes-problem".
              E.g.
              "When it is not easy to promote the fix in the refactored version, you
              did not a good refactoring, because the code should become easier to
              maintain..."
              or maybe "There is a good chance that the refactoring made the
              maintainance fix redundant already." (?)
              If it did not, I also think you are in trouble if you have no test that
              covers the problem that was fixed.
              Greetings
              Ruben



              "barry gervin" <bgervi-@...> wrote:
              original article:http://www.egroups.com/group/extremeprogramming/?start
              =1189
              > This sort of relates to the OpenSource question.
              >
              > The project that I'm working on is a commercial product development
              and I'm
              > trying to visualize how things will be affected if we were to apply
              the XP
              > principles.
              >
              > The way our release cycles work is when we have finished a version
              (say 3.6)
              > we release it to our customers who are ready for a release. We start
              to work
              > on the next version (3.7). In the background however our maintenance
              team
              > does some maintenance on the last version (3.6). Furthermore, if we
              have a
              > big module that will take some time & iterations to get right, we may
              start
              > working on 3.8 as well. By the time 3.7 is ready, we release it to
              customers
              > who are ready for 3.7. Some customers may still stay at 3.6 and
              eventually
              > upgrade to 4.0. They may need some interim fixes, they may even need
              a logic
              > change.
              >
              > The challenging part of this is to refactor mercilessly. I guess this
              is a
              > challenge to begin with - but it's easy to promote maintenance fix
              from 3.6
              > to 3.7 if 3.7 hasn't been refactored mercilessly. I guess this is why
              you
              > need serious test functionality in place or this thing falls down
              like a
              > house of cards.
              >
              > Any input from anyone doing XP in a similar environment.
              > 1) Commercial Product
              > 2) Parallel Version Development
              >
              > Thanks
              >
              > Barry Gervin
              > bgervin@...
              >
            • Fred George
              From: Barry Gervin [mailto:bgervin@gervin.com] Subject: [extremeprogramming] Parallel Version Development: Branching & Merging The project that I m working on
              Message 6 of 23 , Feb 2, 2000
                From: Barry Gervin [mailto:bgervin@...]
                Subject: [extremeprogramming] Parallel Version Development: Branching &
                Merging

                "The project that I'm working on is a commercial product development and I'm
                trying to visualize how things will be affected if we were to apply the XP
                principles.
                ...
                Any input from anyone doing XP in a similar environment.
                1) Commercial Product
                2) Parallel Version Development"

                Let me first say I have had no experience trying to address this problem.
                But, I have given it a lot of thought for my clients...

                Having two XP code bases evolve independently and go _days_ without
                integration is terribly scary, creating _fear_, one of the things XP tries
                to eliminate. Thus, your environment is not conducive to XP. But...

                I believe in Continuous Software Releasing. Rapid iterations combined with
                suites of tests should allow a product to be cut for release quickly. XP
                greatly facilitates this. It's legacy release structures and processes that
                inhibits Continuous Software Releasing.

                If a client wants (for new functions) or needs (defect correction), the
                client obtains the latest release. Maintenance becomes a core development
                function, with defects treated like any other engineering task. Indeed,
                maintenance programs have practiced Collective Code Ownership for years,
                fixing problems in whatever component was necessary.

                Who objects to this? Clients are afraid of new software because its quality
                is suspect. XP's object design, refactoring, and test practices mitigate
                this problem, although it would take time to convince a client that
                tomorrow's code is _more_ reliable than today's (more test cases, more eyes
                have seen it, etc.).

                Traditional test organizations may object: They want to hold code hostage
                for months before "approving" it for release. XP encourages the functional
                tests to be developed in parallel to the code, and run as the code is
                developed. At most, a few days of additional validation should suffice.

                One lesson learned from our JIT manufacturing brethren is that if a process
                needs to be improved by 20%, it is just tweaked. If a process needs to be
                improved 500%, new thinking kicks in and new solutions emerge. JIT was
                borne of just such thinking.

                So you challenge is to recognize and measure the horrible cost of
                integration. To drive out that cost, process changes would need to be
                introduced. And the journey to Continuous Software Releasing begins.

                Fred
                mailto:FredGeorge@...
              Your message has been successfully submitted and would be delivered to recipients shortly.