Why Did We Write the CodePlex Client?

Why Did We Write the CodePlex Client?

  • Comments 10

I want to answer some speculation about what motivated our team to write the CodePlex source control client.

When we chose Team Foundation Server as our source control system, we knew that there would be big reactions to our choice. We knew there would be a decent number of people who wanted the tight Visual Studio integration provided by Team Explorer. For many developers in the Windows space, the Team Explorer GUI is a natural extension of the source control systems they're used to using.

Additionally, though, we heard from a contingent of users who were accustomed to the tools provided by other open source community sites. The biggest difference is support for offline use. Team Explorer builds in a lot of assumptions about working online. Since TFS was designed primarily to support enterprise development on LANs, this seems like a reasonable requirement. When trying to use TFS in the distributed world of open source development, the lack of an offline story can become significant.

We wanted to provide the offline experience for that contingent of users, while preserving the tight integration with Visual Studio for the rest of our users. By developing directly against the TFS web service APIs, we were able to write an offline client that behaved similarly to those available with other environments. The command line version is just our starting point, but we think it hits the critical mass of features to start allowing people to experience TFS source control offline.

Was it six months well spent? I’m sure our customers will let us know. :)

Leave a Comment
  • Please add 2 and 7 and type the answer here:
  • Post
  • This is a great step forward - I applaud the effort and the recognition of its usefulness. For me, it enables automated builds and anonymous source tracking - two of the most important enablers for integrating open source in my other projects.

    One thing which would make it even nicer is an API (instead of just the exe) so I can create in-process build tasks and possibly even shell extensions (though this is a bit far-fetched, since Tortoise sets the bar so high, and managed code is a no-no).

    There are two reasons why this is valuable. One, ad-hoc builds get a bit lengthy when having to launch an external process over and over, rather than just having the client load in-proc once. Two, often an API gives a bit more finesse over the client and/or a nicer overall build task element. Something like <codeplexclient .../> is better than <exec program="cpc.exe"... />.

  • Great work. Just wondering if you plan on exposing a restricted set of webservices for CodePlex site as a whole to enable custom client development.

  • codekaizen,

    We have plans to open up some APIs as well as provide help with builds and such. Our April 24 deployment will contain some of our first efforts in this regards. Having MSBuild APIs exposed for the client is an interesting idea. You should open that as a feature request in our issue tracker. :)

    Kris,

    The CodePlex Client itself is coded against the standard TFS web service APIs. The documentation for the APIs can be found in the latest Platform SDK releases. Be warned, they can be non-trivial. :-p

  • It is definitely 6 months well spent if the client works with non-codeplex TFS instances.

    "this seems like a reasonable requirement" - you are being way too kind. To me, not having a good offline story is the single biggest flaw with TFS. I work in a very large enterprise environment - the exact target market of TFS, and I can tell you the need to be constantly online is a major stumbling block. Let me work from home, on the train, on the plane, in a conference room with weak wireless reception, in a regional office with low bandwidth, etc.

    I know there are ways you can fight with TFS to make it work in those scenarios, but why make me go through the effort when other source control tools have already solved that problem?

    I know you aren't responsible for TFS, so not the target audience for my complaint. But I'm sharing it with you, so you realize what a big advantage it would be to make your offline client work with non-codeplex TFS. You mention it uses the standard TFS API - does that mean it already has no dependencies on codeplex?

  • Ah, just saw your response to my question on your last post. It sounds like this client SHOULD work with any TFS instance. I'll have to give it a try. Thanks for all your work.

    (And by the way, you really should release all of your sourcecode for a site that is trying to build a community of shared source - has there been a published explanation yet?)

  • Joshua,

    I think one of us didn't understand the other one, and I'm not sure who yet. :)

    I interpreted your question to be: "Please document the web service API you used to wrap TFS source control". My answer to that question is: "We didn't wrap TFS source control with an API. We talk directly to the TFS web service APIs."

    The CodePlex Client is designed only to work with CodePlex's TFS servers. You will not be able to use it against any random TFS server. We were looking to solve a problem for CodePlex users, not general TFS users.

    We didn't design something that would be appropriate for general TFS servers, because some of the decisions we made went on the assumption that most CodePlex projects are going to be relatively small. It would be presumptuous of us to assume that our solution is appropriate for all TFS customers; that's the rightful place for the TFS team to decide, given their own knowledge of their customers.

    Now, that isn't to say that there aren't any additional web services involved, because there are. I'll make the suggestion that we document them, but that has its own implications. Right now, this API is private and unsupported, which means we can rev it and break it as we need, comfortable that cpc is the only consumer.

    I'm sorry if I've somehow accidentally mislead you.

  • Well worth it!  I use this over the visual studio source control.

  • Ok, I think I misunderstood you (in a moment of wishful thinking).

    I think you are now saying "we just used the available, documented TFS web APIs to create our offline capable client. You can also use those exact same APIs to create your own offline client (without making use of any of our work because our stuff is TOP SECRET)".

    (That's a playful jab; I'm sure you have your reasons.)

  • In .NET, is anything ever really top secret? ;)

Page 1 of 1 (10 items)