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

RE: [XP] Component-friendly SCMs (was exclusive checkout source c ontrol)

Expand Messages
  • WATKINS, Robert
    ... That s not the problem that I m facing. That s just a given that unit tests get built appropriately. My concern is more around the management and
    Message 1 of 5 , Aug 27, 2003
      Willem Bogaerts wrote:
      > As you do use a source code control system I can only advise
      > you to share the unit tests in all applications that share
      > the components. That way, the component's documentation
      > follows the component and you are sure that the component
      > works in all your applications.

      That's not the problem that I'm facing. That's just a given that unit tests
      get built appropriately.

      My concern is more around the management and reporting. Take CVS for
      example. I can define, in the modules file, that module ProjectX actually
      consists of ProjectX_src, ComponentA, and ComponentB. However, I can't say
      that it uses version 1.1 of ComponentA. This means I can't just do a 'cvs co
      ProjectX' and get the right version of everything; I have to do 'cvs co -r
      PROJECTX_DEV ProjectX'.

      You can solve this a bit by tagging when you version components, and then
      tag again when you use components, but that's a bit unnatural in CVS; it
      seems a lot more natural to work on the HEAD branch. (This will be the
      approach I'm going to take over CVS, in fact). In ClearCase, because there
      is no HEAD branch as such, working on branches seems a lot more natural. I
      dunno, maybe it's just me. Actually, it's not just me; it's everyone else in
      my group who uses CVS, because it's just too easy to work on the HEAD
      branch.

      The reporting is simply a matter of being able to view an update from v1.1
      of ComponentA to v1.2 as exactly that, not as getting new versions of
      various files that make up ComponentA. CVS can't do this because it can't
      version non-files (if you can do directory versioning, you can get a good
      approximation; ClearCase's component version is actually a special instance
      of directory versioning).


      Essentially, I want a tool where using versioned components doesn't mean
      that the developers need to remember that they are using versioned
      components, except when the versions need to be changed. I can live with the
      CVS solution, but I don't like it. :)

      Robert.

      --
      "Software is too expensive to build cheaply"
      Robert Watkins System Architect
      robertdw@... robert.watkins@...


      -----------------------------------------------------------------------------------

      The contents of this message are the views of the Author and do not necessarily reflect the views of SUNCORP METWAY LTD ABN 66 010 831 722.

      The content of this e-mail, including attachments is a confidential communication between the Suncorp Metway Group and the intended addressee. Any unauthorised use of the contents is expressly prohibited. If you have received this e-mail in error please contact the sender immediately and then delete the message and any attachment(s).

      http://www.suncorp.com.au
    • andy.glew@amd.com
      ... When I run into this, I do cvs co ProjectX cd ProjectX make checkout_modules_ProjectX_depends_on I.e. the Makefile records, and version controls, the
      Message 2 of 5 , Aug 28, 2003
        > My concern is more around the management and reporting. Take
        > CVS for example. I can define, in the modules file, that
        > module ProjectX actually consists of ProjectX_src,
        > ComponentA, and ComponentB. However, I can't say that it uses
        > version 1.1 of ComponentA. This means I can't just do a 'cvs
        > co ProjectX' and get the right version of everything; I have
        > to do 'cvs co -r PROJECTX_DEV ProjectX'.

        When I run into this, I do

        cvs co ProjectX
        cd ProjectX
        make checkout_modules_ProjectX_depends_on

        I.e. the Makefile records, and version controls,
        the version dependemcies. (Best if that gets factored
        out into a buildlist of bill of materials file).

        If CVS supported a "post checkout" script,
        this would be further simplified.
        Actually, CVS does support a post checkout command,
        and it is quite useful when using CVS with a local
        filesystem.
        However, with server, remote, CVS, the post checkout
        script runs on the wrong machine.
      • andy.glew@amd.com
        ... Heartily seconded. Echo in the directory structure. Resist strongly attempts to cleanly separate the tests into a separate hierarchy: * project *
        Message 3 of 5 , Aug 28, 2003
          > As you do use a source code control system I can only advise
          > you to share the unit tests in all applications that share
          > the components. That way, the component's documentation
          > follows the component and you are sure that the component
          > works in all your applications.
          >
          > Best regards,
          > Willem Bogaerts

          Heartily seconded. Echo in the directory structure.

          Resist strongly attempts to "cleanly separate"
          the tests into a separate hierarchy:

          * project
          * project/code
          * project/code/module1
          * project/code/module2
          * project/tests
          * project/tests/module1
          * project/tests/module2

          If you do this, it is far too easy for the
          tests to go AWOL.

          Better, if you need to separate the files,
          to create a separate subdirectory

          * project
          * project/module1
          * project/module1/tests
          * project/code/module2
          * project/module2/tests

          I tend to do this, as well as placing test methods
          in some of the module source code files.
        • Steve Berczuk
          ... I read this after my last reply (sorry!) If you want to do this, treat the component development line as a third party codeline. When you have a release
          Message 4 of 5 , Aug 28, 2003
            WATKINS, Robert wrote:

            > You can solve this a bit by tagging when you version components, and then
            > tag again when you use components, but that's a bit unnatural in CVS; it
            > seems a lot more natural to work on the HEAD branch. (This will be the
            > approach I'm going to take over CVS, in fact). In ClearCase, because there
            > is no HEAD branch as such, working on branches seems a lot more natural. I
            > dunno, maybe it's just me. Actually, it's not just me; it's everyone else in
            > my group who uses CVS, because it's just too easy to work on the HEAD
            > branch.

            I read this after my last reply (sorry!)
            If you want to do this, treat the component development line as a
            third party codeline. When you have a 'release' of the component, check
            it in to the Mainline. Now the HEAD of the mainline will be using that
            version of the component. When you rev the component, repeat.

            > Essentially, I want a tool where using versioned components doesn't mean
            > that the developers need to remember that they are using versioned
            > components, except when the versions need to be changed. I can live with the
            > CVS solution, but I don't like it. :)

            Developers never should have to remember this. Another approach is to
            have a script that builds the developers workspace and have the script
            do the revision tagging magic.

            Again, consider asking this on http://groups.yahoo.com/group/scm-patterns

            -steve

            --
            Steve Berczuk | steve@... | http://www.berczuk.com
            SCM Patterns: Effective Teamwork, Practical Integration
            www.scmpatterns.com
          • WATKINS, Robert
            ... It s more about how it impacts developers day-to-day. Most systems I ve seen are pretty ugly, but the ClearCase one was amazingly expressive. I m trying to
            Message 5 of 5 , Aug 31, 2003
              Steve Berczuk wrote:
              > Pretty much any system should allow you to do this... one
              > way is to be
              > sure that the version of the component that you want shares the same
              > label as your mainline release. I'm not sure that I
              > understand whether
              > your question is "how do I perform <some operation> easily in a given
              > SCM?" or rather "what codeline model should I use for this
              > component work?"

              It's more about how it impacts developers day-to-day. Most systems I've seen
              are pretty ugly, but the ClearCase one was amazingly expressive. I'm trying
              to think of how I can get that power of expressive and clarity without
              ClearCase...

              Fortunately, I think Subversion will give it to me.

              Robert.

              --
              "Software is too expensive to build cheaply"
              Robert Watkins System Architect
              robertdw@... robert.watkins@...


              -----------------------------------------------------------------------------------

              The contents of this message are the views of the Author and do not necessarily reflect the views of SUNCORP METWAY LTD ABN 66 010 831 722.

              The content of this e-mail, including attachments is a confidential communication between the Suncorp Metway Group and the intended addressee. Any unauthorised use of the contents is expressly prohibited. If you have received this e-mail in error please contact the sender immediately and then delete the message and any attachment(s).

              http://www.suncorp.com.au
            Your message has been successfully submitted and would be delivered to recipients shortly.