What is best in git?

What are the things you'd first say about git when describing it to someone?

• That it's distributed?
• Ot makes branching easier or more lightweight?
• You absolutely hate it's complexity?
• Each repo is a peer?
• It's fast?
• It works when you're disconnected from remote repos?

I think the most important thing to know about GIT is that each commit represents a state of a file. With SVN, each commit represents a diff between two file states (a changeset). With git, the diff is calculated on demand by comparing two commits. With svn, the state of the file is calculated by applying the changeset.

Putting my personal projects on Subversion

Several personal projects, including the ones I've done for job interviews, little tutorials I've made for myself, and the tool for EvE Online.
I noticed recently that DreamHost offers free svn hosting, and I just got around to jumping on that. Funny - it just feels SO good to give those projects a proper home. I just don't feel like code is in any stable state until it's in a VCS. :)
Unfortunately, in order to get DreamHost to let me run Atlassian Jira/Greenhopper and Jetbrain's TeamCity, I'd need a Virtual Private Server plan with them so I can run tomcat. I doubt that's worth it at the moment.
Still, it's nice to have a home for my code :)

Most of it is in private repositories, but I've exposed MarketAgent (read-only).

The clearest and most complete ReST(ROA) and SOAP(SOA) comparision I've ever seen

Of the many clarifying nuggets in this article, I got from it:

• ROA is resource-centric, with the resource specified by the url, and the client specifies the method (GET, PUT, etc) to be called on the resource.
• SOA is service-centric, with the service specified by the url, and the client specifies the resource upon which the service is to be performed.

InfoQ: Is REST the future for SOA?

From Red Tape to No Tape - Part 2: A Self-evaluation to Recognize Organizational Misalignment with Agile Values

From Red Tape to No Tape - Part 2: A Self-evaluation to Recognize Organizational Misalignment with Agile Values

And here's the second part.

Here are a couple of contrasting elements of each company structure:

Bureaucratic vs. Post Industrial (Agile)

Hiring is viewed as fulfilling an immediate skill set need.

Hiring is viewed in the long term with cultural fit and individual contributions outside of skills being considered.

Language in the meetings focuses on I, me, individual contribution.

Language in meetings focuses on team and collective contribution.

maven release plugin

It's magic, yes, but for the odd piece.

When I'm ready to send a release candidate to QA, I expect to make a release branch. Mainline development can continue, and if I need to fix a bug QA has found I can make it in the branch and merge it to trunk.
When I think of vcs "tags," I think of some marker that indicates that a release was made from "this revision."

It seems that the maven release plugin expects that your code is perfect when you've run "mvn release:prepare." For subversion, it creates an "svn copy" in your "tags" directory. While in svn, that's no different from a copy in a directory of any arbitrary name, it, by convention, implies "no further work in this copy."
So that's sort of in conflict with how I want to use it. I want it to make an "svn copy" in my "branches" directory, because I expect I might need to patch it.

You can set a "tagbase" variable to point to your "branches" directory, but while it (presumably) works if you set it to something arbitrary (say, "mytags"), it doesn't work when you set it to "branches."

So, I've just "gotten over it," and I'm using "tags" for release candidates that might get modified.

:(

From Red Tape to No Tape: Maximizing Agile in Your Organization - Part One

From Red Tape to No Tape: Maximizing Agile in Your Organization - Part One: "By limiting people’s creative thinking, initiative, and ultimately sense of control over their work, some of the major advantages of agile are quashed; the ability to push decisions to the level of the organization where the work is (and therefore the most is known about the work) and the ability to use many minds to collaborate in ideas."

Don't checkin ToDo

That's what I think, anyway.

ToDo markers generally shouldn't survive a commit.
If you commit code with ToDo markers in them, you're not done with your current, discrete piece of work yet.
Oh! The ToDo notes are for some other piece of work? OK, then I think it's best if they're entered into an issue tracker, and you delete the ToDo. Then you can check in.

Because ToDo work gets lost. How many times have you seen some ToDo marker in your code that's been there who knows how many months (years?)? Was it important? Is it still important? Is this what's been causing that weird bug?
The whole point of an issue tracking system is to make sure the work you want to get done gets done, and nothing else. If you're supposed to do it, it goes in the issue tracker. If it's just an ephemeral indicator of work to be done in this checkin, then ToDo is a perfect reminder.
The best IDEs offer a window in which you can see all your ToDo markers and go wrap them up before you check in. (Or make issues out of them)

---

Edit (May 17):
Intellij Idea just released v10.5. On their "What's new" page, I see they agree with me: