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

Re: [XP] Re: For product development with XP, CVS branching and merging seems difficult.

Expand Messages
  • Steve Berczuk
    ... This is sort of what I meant earlier when I referred to their being architectural solutions to this, but what do you do to support a deployed customer
    Message 1 of 43 , Feb 28, 2003
    • 0 Attachment
      Ron Jeffries wrote:
      > Yes. This requirement does not, however, argue for branching the code. It
      > argues, instead for partitioning the code into (in this case) three
      > partitions: common, v1, and v2. If the code with the bug in it occurs in
      > both version 1 and version 2 (the case in point), then it wants to be in
      > "common". There are two build procedures, no branching.
      >
      > (Now some may argue that this is indeed branching. Not in the spirit of
      > the thing I'm after, the appearance of separate copies of the same code
      > in two versions of some program.)

      This is sort of what I meant earlier when I referred to their being
      "architectural solutions" to this, but what do you do to support a
      deployed customer with v1? and how do you deal with changes in common
      over time? (at some point you may have a common that works with v1, but
      not v64).

      A proper partitioning is ideal in many (but not all?) ways, but it
      requires a LOT of foresight to do thye partition before you deploy a system.

      Then again, Maybe I just don't understand what you mean by :
      "the appearance of separate copies of the same code in two versions of
      some program." do you mean 'identical code' in two versions?

      -steve

      --
      Steve Berczuk | steve@... | http://www.berczuk.com
      SCM Patterns: Effective Teamwork, Practical Integration
      www.scmpatterns.com
    • Steve Berczuk
      ... This is partly an architectural solution, but the identification of what components comprise v1 or v2 is what a SCM system does for you. But there are a
      Message 43 of 43 , Mar 6 2:28 PM
      • 0 Attachment
        Tim Moore wrote:
        > OK, I think I need to illustrate what I'm talking about. It's
        > definitely NOT copying the whole codebase into multiple projects. In
        > fact, that's the opposite of what I'm talking about. What I'm
        > talking about is pulling the *differences* between v1.x and v2.x into
        > separate projects, and leaving the common parts in a single third
        > place. Then v1-branch code is created by assembling common+v1, and
        > v2-branch code is created by assembling common+v2.

        This is partly an architectural solution, but the identification of
        what components comprise v1 or v2 is what a SCM system does for you.
        But there are a number of issue that we are, umm, merging together :)
        1. The difficulties of merging
        2. doing parallel dev on multiple releases of a product
        3. Deciding when to branch...

        you can avoid 1 by doing a branch and just treating the codelines as
        seperate, but at least you maintain the version history, tracability,
        etc... A better tool helps, and I have never understood why
        organizations will waste $$$ by using a tool like VSS when there are
        inexpensive or free alternatives (like CVS). I admit that trying to
        branch in VSS can make one leery..

        > And at a deeper level of organization distress, we keep having
        > situations where we release a product, start work on the next major
        > version, and then have to do a lot of major changes in the old
        > codeline.

        This is exactly what a branch is for. (And I too have many stories
        about organizational distress... see my book ;) )
        > Let's say we have a hello world class in v.1 that is supposed to
        > print "Hello, world" ten times. Let's say that this is the code
        > shipped with
        In the below example, it seems like the lower risk change is to fix v1
        to do < 10 rather than add the getLocalizedString() method.... This way
        you are fixing the problem and ONLY the problem (AND it is the simplest
        thing that will work ;) )

        Adding the methods, extending the classes, etc could break all sorts of
        things. Whereas if you just fixed both implementions (albeit seperately,
        unless your diff/merge tool can fix the diff), you may not even have to
        change the tests at all. If you change class names, etc you have to
        change more things...


        > Of course you'd need to do something similar with the tests, and
        > you'd need to introduce some kind of factory to construct the correct
        > concrete class for the version you've built, etc.
        Not if you just fix the bug in V1.

        > But does that make any sense? It's OAOO, and you can easily see the
        > differences between v1 and v2. On the other hand, some things
        > (config files, other resources) might not be split up as easily as a
        > class is. I'm not sure that this is really a good idea at all now,
        > but it passes the criteria of only requiring one fix (without
        > merging) to solve the problem in both versions.

        But you are jumping through all sorts of hoops and doing MORE work. This
        is sort of like writing a C++ function which has a a this pointer as an
        argument, rather than adding a method because your change control
        process for adding a method is harder than the one for adding a
        function... It works sure, but it is likely to bite you later.

        > And it's independent of any particular tool. It is kind of a lot of
        > work, though. Maybe if I had more confidence in my SCM tool then I
        > wouldn't even be proposing this.
        Yep , that's what it sound like :)



        (I left the example below for reference)

        > v.1:
        >
        > public class HelloWorld { public void printHelloWorldTenTimes() { for
        > (i = 0; i <= 10; i++) { System.out.println("Hello, world"); } } }
        >
        > And let's say that for whatever reason, our tests miss the fact that
        > this actually prints the message eleven times, and we ship this to
        > hundreds of customers. We then get started on version two, which
        > will be fully internationalized and cost twice as much. So let's say
        > we make this change:
        >
        > public class HelloWorld { public void printHelloWorldTenTimes() { for
        > (i = 0; i <= 10; i++) {
        > System.out.println(getLocalizedString("Hello, world")); } }
        >
        > private String getLocalizedString(String key) { ...look up key in
        > resource bundle or whatever } }
        >
        > Then we get a bug report in from a customer about the ten vs. eleven
        > thing. Uh oh...gotta ship a v.1.0.1 now, but we want to make sure
        > that the fix is in both versions. So we do something like this:
        >
        > public abstract class HelloWorld { public void
        > printHelloWorldTenTimes() { for (i = 0; i < 10; i++) {
        > System.out.println(getLocalizedString("Hello, world")); } }
        >
        > protected abstract String getLocalizedString(String key); }
        >
        > Create new project v1, and add this class:
        >
        > public class HelloWorldV1 extends HelloWorld { protected String
        > getLocalizedString(String key) { return key; } }
        >
        > Create new project v2, and add this class:
        >
        > public class HelloWorldV2 extends HelloWorld { protected String
        > getLocalizedString(String key) { ...look up key in resource bundle or
        > whatever } }
        >


        --
        Steve Berczuk | steve@... | http://www.berczuk.com
        SCM Patterns: Effective Teamwork, Practical Integration
        www.scmpatterns.com
      Your message has been successfully submitted and would be delivered to recipients shortly.