in

CodePrairie .NET

South Dakota .NET User Group

chrisortman

February 2008 - Posts

  • How do you manage your open source software

    I have several projects all using a combination of open source software.

    Castle

    NHibernate

    Rhino

    MbUnit

    log4net

    Are the first ones that come to mind.

    In some of these cases I am always running off the trunk which means I am building everything myself. This can get pretty complex to manage, especially when the code changes frequently. I'd like to hear from you how you are dealing with some of these issues.

    How do you handle updates?

    How do you manage your own changes?

    How do you integrate it with your build process.

  • ReSharper 4 nightly builds coming soon!

    So excited am I, here's the announcement from Ilya Ryzhenkov. The full thread is here

     

    Hi,
    Here is updated information about ReSharper 4 public availability.
    1. Nightly builds are planned to start publishing tomorrow (in about 24 hours),
    when it will be February 15 evening here. Our apologizes to those who live
    ahead of our time :)
    It may very well happen that we delay public builds if we find critical problem
    in our product. We hope you understand. We won't delay it "just in case".
    2. No stable EAP builds in near future. We have to do a lot before we begin
    stabilization phase. However, we use current development builds all the time,
    so any critical problem will most likely be fixed within a day or two. After
    all, we are going to open public builds because YOU asked for it :)
    3. If you are going to download nightly builds, it is HIGHLY recommended
    to register in our JIRA issue tracker. We will ask for additional information
    for exceptions and problems reported, so we want to talk to someone other
    than Mr. Anonymous. Actually, we usually just ignore anonymous exceptions,
    if they are not plain obvious, because it is almost impossible to reproduce
    them without additional information. When you complete your registration
    in JIRA, please include your credentials in ReSharper exception submission
    dialog.
    You can read more about our issue tracking policy here: http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+Issue+Tracker
    4. Information about what to look for in ReSharper 4 and what features are
    ready or not will be available simultaneously with first public build.
    Thank you for your interest in ReSharper 4!
    Sincerely,
    Ilya Ryzhenkov
    JetBrains, Inc
    http://www.jetbrains.com
    "Develop with pleasure!"

  • Why frequent commits are important

    Something I have noticed has changed about the way I work now that I use git instead of subversion is that I make a lot more commits.

    Let's say that in order to add feature X I need to make the following changes

    Add migration
    Add ActiveRecord model Foo
    Add PersistanceTests for model
    Write Tests for feature X
    Rename an existing class
    Change the way some other model class works
    implement some behavior in Foo
    Ensure that tests pass

    In a lot of code I've seen all these changes would be grouped into a single SVN commit

    svn commit -m "Implemented feature X"

    But when that is the case a lot of information gets lost about how feature X got implemented.

    I think that each of those changes should be their own commit with their own explanation. Centralized version control doesn't help this though because I would get impatient with making 3 minutes worth of changes and waiting 30 seconds to make the commit. I also think that pushing each change out to everyone else before the whole feature is ready would be a bad thing.

    Using a DVCS (such as git) it is painless to do this. The commits are fast, and I just because I commit doesn't mean I need to share. I also have the freedom to go back and rewrite history if I realize while I'm implementing some behavior in Foo that I forgot a column that should have been part of my initial migration.

  • Why I <3 git rebase

    I recently started adding a new feature to one of my projects. The first thing I typically do in this scenario:

    git checkout -b name-of-feature current-version (replacing name-of-feature and current-version appropriately)

    Now as I'm working on this I may bump into something that if I were to refactor would make this new feature a lot a lot simpler to implement.

    If I were using only subversion and I started on this refactoring I would have a source history that looks something like:

    Added migration for table x

    Created new models + tests for feature X

    Renamed class foo to bar

    Refactored some service into separate services

    next change for feature x

    fixed bug 370 reported by QA

    another change for feature X

     

    Which isn't bad persay, but it would be better if things were in their proper order. I also don't like that I would have to commit some incomplete implementation of feature X just to fix a bug. If I had a little better foresight and planning I might have fixed the bug first, then done that refactoring that will make feature X simpler then actually implemented feature X. Fortunately git makes this pretty easy to do.

    Here's what my output of git branch might be:
    v1.2
    add-feature-x
    refactor-some-service
    fix-bug-370

    v1.2
           |
            -------add-feature-x
                                          |
                                           ---------refactor-some-service-----
                                                                                         |
                                                                                          ----fix-bug-370

    In my graph here a - represents a commit and | a branch point
    What this says is that I started adding feature x, did some refactoring, stopped to fix a bug and continued my refactoring after.

    Just because things happened in this order is no reason that history must say they did. I guess I like the Back to the Future theory of time travel better than Terminator.

    Since I haven't shared these changes yet, I can fix up my history.

    git co fix-bug-370
    git rebase v1.2

    I now have

     

    v1.2
           |
            -------add-feature-x
           |                             |
           |                              ---------refactor-some-service-----
           |------fix-bug-370

     

    And a couple more times:

    git co refactor-some-service
    git rebase fix-bug-370
    git co add-feature-x
    git rebase refactor-some-service

    So that I now have                                                                           

     

    v1.2
           |
            -------fix-bug-370
                                      |
                                       ---------refactor-some-service-----
                                                                                          |
                                                                                          ---- add-feature-x

    Which when I eventually do

    git co v1.2
    git merge add-feature-x

    Will produce a nice linear history in the order things should have happened.

    Posted Feb 14 2008, 07:27 AM by chrisortman with no comments
    Filed under:
  • How to execute a VIM macro over a line range

    Macros in VIM are extremely useful for making lots of changes.

    One thing that has always bothered me though is that I couldn't run the macro over a movement or line range and had to run it manually for each line.

    The secret sauce is the :norm command.

    Say you have recorded a macro in the q register.

    To apply it to lines 3 - 6 use:

    :3,6norm! @q

    If you like VIM and want to learn more, I suggest you check out Aaron's screencasts.

Powered by Community Server (Commercial Edition), by Telligent Systems