February 2008 - Posts

How do you manage your open source software

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

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.

Posted Feb 19 2008, 07:51 PM by chrisortman with 2 comment(s)

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!"

Posted Feb 15 2008, 07:37 AM by chrisortman with no comments

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.

Posted Feb 14 2008, 07:40 AM by chrisortman with no comments

Filed under: Subversion, git

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

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: git

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.

Posted Feb 06 2008, 05:17 AM by chrisortman with 4 comment(s)

Filed under: General

CodePrairie .NET

This Blog

Syndication

Recent Posts

Tags

Archives

chrisortman