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

[XP] Re: XP and SCM (CVS)

Expand Messages
  • Andy Glew
    Recent posts have touched on this, but I would like to ask some specific questions about XP and the software configuration management tool CVS. I refer to some
    Message 1 of 1 , Mar 15, 2000
    • 0 Attachment
      Recent posts have touched on this, but I would like
      to ask some specific questions about XP and the
      software configuration management tool CVS.
      I refer to some of Brad Appleton's SCM patterns
      but approximations of their names.

      Q: Do XPers use "Checkin Early and Often"?
      A: I think so. Small steps and continuous integration,
      right?

      Some variants of "Checkin Early and Often"
      encourage not-necessarily working code to be
      checked in -- but checked in on a private developer
      branch, not merged into the "Latest and Greatest" branch
      shared by all developers, and certainly not released.

      (Note: some SCM patterns distinguish LOG and release
      to other developers.)

      Q: do XPers using CVS use private branches?
      Q: do XPers using CVS checkin broken code onto private branches?

      Some of Kent's comments make me suspect that the answer is "No".

      That will be a harder pill for me to swallow than most of XP;
      "checkin early and often" has been one of the most successful software
      practices I have learned over the years.

      I'm not necessarily sure that XP is incompatible with
      "checkin early and often" and private branches;
      I'm afraid, however, that some aspects of the CVS toolchain
      make them harder to combine.

      So, here's my real question:

      Q: how do you combine XP with CVS checkin early and
      often on private branches?


      Here's my usual development rhythm using CVS:

      ** I start off with a view of the latest and greatest
      development branch.

      ** I pick up a task item.

      ** If the task looks really small, I test & code it,
      and check it in. No intermediate checkins.

      ** If the task looks big enough, I start a branch
      cvs tag taskname--branch-base
      cvs tag -b taskname--branch
      cvs update -r taskname-branch
      (Actually, what usually happens is I start coding.
      If I get to a point where I feel that an intermediate
      checkin is necessary, I start the branch - which is
      effective on the original file versions.)

      I test, code, do intermediate checkins, on the branch.
      When I think I have finished a chunk of functionality,
      I update myself wrt the main branch
      still on my local branch
      cvs tag taskname--updating-wrt-main
      cvs update -jmain-branch
      ...test and code
      cvs ci
      cvs tag taskname--updated-wrt-main
      (not necessary if single person developer, not multitasking)

      Then I update the main branch
      cvs update -rmain-branch
      cvs tag taskname--merge-into-main--before
      cvs update -jtaskname-branch
      ...verify, fix if necessary
      cvs ci
      cvs tag taskname--merged-into-main--after

      Side notes:
      Note that the before and after tags are not an atomic action
      in CVS. You may have to move them if the update has conflicts.
      I like this pattern, but find that the speed of CVS sucks greatly,
      especially given the multiple scans of the entire source tree
      that I do not know how to combine into one. On bad days,
      each such scan make take 15-20 minutes.
      I sure would like to have retroactive branching.
      Each branch defines a "change packet".

      Apart from this relatively minor side issues, the biggest problem
      I have with XP and the use of private branches is in refactoring.

      Example:

      I'm working on a branch. I see a refactoring. I do it. I check it in.
      But then, eventually, I decide to throw the whole branch away.
      It's a real pain, because then the generically useful refactorings
      on the branch may become lost work. Or, almost equally painful,
      merging in just one refactoring from several changes made on a branch.

      I've tried the converse without much success:
      I'm on a task branch.
      I see a refactoring.
      I start a new branch for the refactoring - perhaps off
      the main branch, perhaps off the task branch.
      I update the task branch with the refactoring.

      If I now throw away the task branch,
      if I started the refactoring branch off the task branch,
      I can at least update the main branch.

      If I started the refactoring branch off the main branch,
      I will probably have merged it into the main branch.

      Both of these outcomes are okay.
      But, if I don't throw away the task branch,
      merging the task branch + refactoring
      into the main branch + refactoring
      now has a habit of producing needless CVS conflicts.

      Particularly when the refactoring involves adding
      files. CVS does not seem to handle a file being added
      on two different branches well; it seems to prefer files
      being added on a common ancestor.

      Many of these needless CVS conflicts deal with
      embedded version strings, like $Header: $.
      I know, I know: many CVS people don't do $Header: $,
      and certainly not $Log: $.
      Unfortunately, my externally provided code base does...
      I haven't yet had the courage to delete all of the $Log: $
      crap, although I probably should; I really don't want to
      delete $Header: $ embedded version numbers, or disable
      their expansion. I use them to do configuration management
      of archived performance data.


      ===

      OK, by now you are probably persuaded that my CVS usage model
      is all wrong. So, what do XPers who use CVS do?
    Your message has been successfully submitted and would be delivered to recipients shortly.