Subversion support (SVN)


CodePlex is a very nice and practical community website, yet I really miss the Subversion repository provided by Sourceforge or Tigris. Many pure .Net developers (like myself) are using Subversion. It would be a really nice community gift to support SVN as well that VS Team system.

Closed Sep 16, 2008 at 9:08 PM by
You can now access CodePlex using SVN Clients with the following URL:


More information for using SVN clients can be found in the CodePlex FAQ:



jwanagel wrote Jan 7, 2007 at 8:45 PM

What features of Subversion do you miss the most?

WShelley wrote Jan 21, 2007 at 5:46 AM

If TFS had a multiplatform client, i think there would be no need for subversion.

cuppm wrote Feb 4, 2007 at 12:27 PM

I use SVN all the time with the TortoiseSVN client. Having it completely external to any development tool and integrated with Explorer makes it extremely flexible and powerful. Sure when I'm working on the big project, I'll have VS open. But if I want to look at files trying to find stuff and make a quick change to documentation or do version compares, I use other tools because they're faster.

sontek wrote Feb 5, 2007 at 5:21 AM

Anonymous/Read only access would be nice

dcazzulino wrote Feb 5, 2007 at 5:24 AM

-1 on this.If a standalone shell (like Tortoise) or .NET client existed, there would be no need for this.Hell, even a comprehensive set of powershell cmdlets could do! ;)

roelofb wrote Feb 5, 2007 at 8:18 AM

Jonathan Wanagel at Ayende Rahien's blog: 'Unfortunately TFS isn't scalable enough to support all the anonymous users on CodePlex, so we restrict SCC access to project team members only. We're investigating ways to get around this.' http://www.ayende.com/Blog/archive/6904.aspx

Seems to me SVN is a good way around this, it scales, has standalone clients and is generally easy to work with. I understand Microsoft has a different agenda here (-1 voting does not really help without giving alternatives) but there are no standalone clients anywhere in sight and powershell cmdlets feel awkward and are unportable. And it does not fix the scaling issue of TFS. Read Ayende's blog as to why having SCM access is important if you want to build an open source community.

stingray wrote Feb 9, 2007 at 11:52 AM

I think Microft created Codeplex in the first place to promote Team System. So why would they include support for SVN? I'm an avid SVN / TortoiseSVN user myself, but I think this vote is kinda unrealistic.

jwanagel wrote Feb 10, 2007 at 8:02 AM

It's important to us for CodePlex to work well for the open source developers using the site. If Subversion support is important, then voting is important to let us know.

jafin wrote Feb 15, 2007 at 6:49 AM

Features of Subversion I miss:
  1. The fact that there are at least 5 variant subversion clients to use. You aren't just stuck with 'the TFS client'.2. Anonymous checkout (more just a setting rather than a feature of the client. Im sure the TFS client can do this.3. The fact that it is multiplatform (mayby not so useful on a .net codeplex.
  2. (Not a client feature, a svn backend one) Web based browse access to code. Nice to have to quickly scan stuff. May also be useful to search engines like Google code search to index.
  3. Ubiquity (I know its not a feature). But a bucket load of o/s developers use Subversion/cvs as they are almost the defacto for this kind of thing.
I am kinda in the same boat with Stingray's comments. If this site was setup to promo TFS then I really wouldn't see MS wanting to waste time having exposure to an alternative source client. Although I do think it would be a major feather in their hat if they could somehow work with svn. But if this site was setup to host open source projects as a courtesy from Microsoft to be more community friendly then they seriously should consider this Vote.

dcazzulino wrote Feb 19, 2007 at 6:15 PM

Ability to work offline comes to mind. You can simply do a submit of the changes from an entire folder structure and get everything added/changed/deleted as required.

But I still don't think this is an important issue. I'd like to vote -1 then.

melliott wrote Feb 21, 2007 at 8:03 PM

I think cuppm hit the nail on the head...at least I'm in the same boat.

codekaizen wrote Feb 21, 2007 at 10:59 PM

Anonymous checkout / diffing is the only thing I'd need SNV for. If TFS on CodePlex did this, I wouldn't need it - tf.exe would be fine. I'm in complete agreement with Ayende - if there is no SCM truth for me to diff and run with, I don't want to get involved. Not getting a bunch of people involved isn't the way to build a community... in my experience at least.

terrajobst wrote Feb 24, 2007 at 3:38 PM

First of all I have to say that although I like Team System currently I don't see real benefits from using it at CodePlex. What makes TFS great are IMHO the following features:
  • server sided builds- unit testing with automatic code coverage analysis- integration between issue tracking and version control.- in-depth reporting of automatically collected code metrics like code churn, unit test quality etc.- integration into MS Project and MS Excel- customization of process templates
Although some of these features are usable by CodePlex users (e.g. associating work items with change sets) a lot of them of them are exclusively restricted to users of VS Team System clients (like unit testing and code coverage) or are not exposed at all (e.g. reporting, builds, custom project process).

To me, providing an alternative version control system makes a lot of sense for an open source community. So the users can choose which version control fits best their needs.

In order to answer jwanagel question what we miss most:
  1. Banching is currently better supported in SVN. It is faster, easier to track and conflicts are easier to resolve. However, I know that in practice branching seems not beeing used by many users but I like branches a lot. It can really help you with maintaining a healthy code base and creating new features while keeping the agility of beeing able to create a bug fix for any release at any time. I also use them for experiments (although the shelving feature is great, using branches seems to be both more comfortable and powerful).
  2. File comparisons against the workspace version of a code file are much faster in SVN. The reason for this is that SVN stores a local copy of the repostiory version the local version is related to. Before I do any checkin I like to review all changes I am going to commit. This requires me to right click all files in the Peding Changes pane and choose "Compare -> With Workspace Version" which is both laborious and time consuming. Note that in TortoiseSVN I only need to double click the file in the checkin window.
  3. Real offline support. Due to the architecture and integration of TFS SCC working without an internet connection does not feel as natural as in SVN. First I have to check out the whole project with all files. Although check outs are non exclusive by default I am forced to not forget this. Merging all changes back then is again a lot of work and a bit cumbersome.

jimnewkirk wrote Feb 25, 2007 at 8:11 PM

Just to set the record straight. CodePlex was not created to promote Team System. Its goals are to host and support open source projects.

JoeBlack wrote Feb 27, 2007 at 2:08 PM

Is this an ETA to this feature? I would love to use SVN over TFS. I found TFS is a little too complex for my liking. I love simple source check-in/check-out features without having to create workspaces and having to worrying about shelving. MS, please advice if you are indeed going to provide support for SVN or CVS. Thanks!

JonathanMcCracken wrote Feb 27, 2007 at 4:07 PM

I'd agree that support for subversion would broaden the number of open-source developers who would use CodePlex. SVN is simple and light-weight, where TFS is more heavy-weight and less supportive of distributed (and disconnected) development. Just my 2 cents.

SharpForger wrote Feb 28, 2007 at 10:42 AM

http://codeplex.com/SharpForge has alot of what is being requested here, it doesn't require TFS and is released under the BSD license.

) Support for both Apache and SvnServe as the server or don't use Subversion at all ) Users can setup their own projects, no administration is required to create Subversion repositories, give users access or managing role based authenticated read/write access ) anonymous read access is supported ) wiki content is loaded directly from the repository so its versioned, has authenticated read/write access and diff's, you can also link to images and other content in the repository or externally. ) wysiwyg rich text editing for releases, forum posts and work items ) browse source code online *) easy installation

Haacked wrote Mar 2, 2007 at 10:25 PM

Here's another key benefit of SVN - Patch support.

This goes hand in hand with anonymous access. Users without commit access can have Subversion generate patch files consisting of their changes and submit these files. This makes it really easy for the casual contributor to quickly submit a patch as well as makes it easy for the Open Source development team to apply contributions to the source.

This is a huge benefit to the project.

Unfortunately with CodePlex, you either give commit access or you don’t. If you don’t, it’s a pain for users to submit patches and a pain for the project team to apply patches.

orand wrote Mar 3, 2007 at 12:09 AM

There's only so far you can go to make checkout-edit-checkin look and feel like edit-merge-commit. In the end, the proposed edit-merge-commit look-and-feel hacks even for v2 are still going to be unacceptable to people who know and love the edit-merge-commit style that is a fundamental part of open source development. Based on private correspondence with Brian Harry, this problem won't be solved as long as he's calling the shots. He's betting that in v2 they can put enough edit-merge-commit lipstick on the checkout-edit-checkin pig that most people won't know the difference, but you can't really get that right that without giving up the "advantages of checkout" that Brian loves so dearly.

renesisx wrote Mar 6, 2007 at 10:04 AM

This would be great. My project is aimed at deployment on Mono as well, and therefore it rules out TFS as source control.

Redth wrote Mar 15, 2007 at 6:24 PM

I won't use codeplex until there's subversion support. That simple. I've moved to coding in sharpdevelop for now.

Bjoern wrote Mar 23, 2007 at 2:51 PM

The lack of SVN style edit-merge-commit support is pretty annoying when using any of the VS Express SKUs, e.g. the need to switch to either the command line or the Team Explorer to explicitly notify the server about my intention to edit one or more files - but that seems to be an issue with TFS and the lack of SCM support in the Express SKUs and not CodePlex...

justinc wrote Mar 24, 2007 at 12:05 AM

TFS is better than SVN, there is no need for this feature (not to mention being virtually impossible). Why wouldn't the TFS libraries work under Mono? Just make a SVN like interface that wraps the TFS API.

jflouret wrote Mar 28, 2007 at 12:12 AM

CodePlex could add add a full source control client accesible through the web like TeamPlain (http://www.devbiz.com/teamplain/webaccess/default.aspx). It would aliviate many of the problems described here.

jwanagel wrote Mar 29, 2007 at 4:20 PM

TeamPlain isn't a source control client. It offers online source code browsing, but no checkout/checkin functionality.

camalot wrote Apr 1, 2007 at 3:44 AM

no teamplain isn't a client, but you can use the CodePlex Client beta to do checkin/checkout outside of visual studio. http://www.codeplex.com/CodePlex/Wiki/View.aspx?title=CodePlexClient&referringTitle=Source%20control%20clients

WShelley wrote May 8, 2007 at 1:10 AM

I've received several complaints already from people in other communities (e.g. IRC) who inform me that without anonymous source control access, and the ability to create patches, they are basically unable to contribute changes to my project.

These are people with access to both windows and linux systems, and most of them have visual studio 2005 standard or better.

Even if codeplex did not host the subversion servers themselves, it would be nice if they were able to integrate viewing of the subversion commits into the "source code" tab in each project.

sodablue wrote May 17, 2007 at 10:27 PM

I don't reall care for Subversion... That being said, I think some of the features mentioned here are important. Not just to Codeplex, but to TFS. Ability to work disconnected, and so on.

jimnewkirk wrote May 18, 2007 at 11:57 PM

We're adding support for TortoiseSVN.

Haacked wrote May 21, 2007 at 9:25 PM

Jim, I assume that means by rolling out Subversion, right? Or have you created some sort of Subversion to TFS bridge?

jimnewkirk wrote May 22, 2007 at 12:40 AM

Phil, yes. We created a bridge. We are not rolling out Subversion servers.

jimnewkirk wrote May 22, 2007 at 12:41 AM

To clarify: it's our intention to support the functionality of the command-line Subversion client as well as TortoiseSVN.

Haacked wrote May 22, 2007 at 1:24 AM

So I can download svn.exe from http://subversion.tigris.org/ and manage my CodePlex source code repository, yes? So are you rolling out Subversion? Or a Subversion facade into TFS? Anything you can reveal? :)

spookytooth wrote May 22, 2007 at 1:28 AM

While I think the sentiment of supporting Tortoise and svn.exe is wonderful, I don't think it addresses the primary issues here: anonymous access and browsing, patching, etc. I think it might be a bit misleading to set a Release Date for this when it's really not addressing the work item.

jwanagel wrote May 22, 2007 at 1:56 AM

Anonymous access will be supported.

erickemp wrote May 22, 2007 at 2:01 AM

Offline support?

jwanagel wrote May 22, 2007 at 4:56 AM


jwanagel wrote May 30, 2007 at 12:38 AM

We have revised the release date for this feature to June 18th to give some additional time on the development and testing. We have also announced that the source code for the bridge will be released as an open source project on CodePlex.

jwanagel wrote Jun 19, 2007 at 6:12 PM

SvnBridge has now been published at http://www.codeplex.com/SvnBridge

simone_b wrote Jun 19, 2007 at 8:51 PM

June 19 and still not seeing anything official... SvnBridge has no releases yet, so you still have to use tfs to get the source.

cesarbrod wrote Jun 26, 2007 at 7:21 PM

This is all quite frustrating. I work with a team that is already familiar with SVN and we were looking forward for the June, 5th release date, including SVN support. If this was going to be through a bridge, Ok, as long as anonymous browsing was allowed, sycing with local SVN for offline work and some other features already listed in several comments here. SVN support is so important it is, by far, the most voted feature here. Having said this, I look forward to see SvnBridge evolving.

codekaizen wrote Jun 26, 2007 at 11:29 PM

Yo, cesarbrod - check out the SvnBridge project here: http://www.codeplex.com/svnbridge . I use it every day and it's pretty solid.

Speaking of this, why is this issue still open?

rstuven wrote Jun 28, 2007 at 1:44 AM

@codekaizen,I think this issue should keep open. SvnBridge is not stable yet and it doesn't work with Mono runtime. This issue should be closed when SvnBridge be integrated with Codeplex at the server side (server version of SvnBridge is planned for post version 1)

codekaizen wrote Jun 28, 2007 at 6:47 AM

@rstuven -

Fair enough: I do eagerly anticipate the server-side solution.

Good to see the work continuing on the SvnBridge at the pace it is. Each day this week has brought better stability. Anonymous access is now supported, as well.

dgv wrote Sep 6, 2007 at 10:36 AM

Subversion is the most used VCS today. Support for Subversion would show that Microsoft is supporting Open Source move and not uses it to promote its products. It's fine to have TFS but something like SvnBridge should be really finalized and integrated with CodePlex. In my opinion a better option would be to have a choice which VSC to use when creating a project:
  1. TFS2. Subversion
And then have a bridge Svn TFS so that everyone will be happy.

jwanagel wrote Sep 6, 2007 at 3:06 PM

Our goal is to have the broadest source control client support and have all clients work with every project. If we let people choose the actual server implementation then it would make it a lot harder to allow all source control clients to work with every project (we'd need to create a bridge for every client type to every server type). We do plan on integrating the server version of SvnBridge into CodePlex so people don't need to run it on their local machine.

Pon_the_Pony wrote Oct 16, 2007 at 8:45 AM

This work item really should be closed.

jwanagel wrote Oct 16, 2007 at 3:29 PM

We're planning to close it once we deploy the server version of SvnBridge.

JustinJosefAngel wrote Oct 27, 2007 at 3:28 PM

I have to disagree with this one.
Codeplex is TFS driven. Everything else is glitz.
And there seems to be nothing missing that can't be added on TFS.

rsagula wrote Dec 9, 2007 at 12:08 AM

SVN support would be great. It's a deal breaker for me.

bsimser wrote Dec 18, 2007 at 12:42 AM

ETA on server version of SvnBridge? This is a needed feature as several recent projects have decided to setup shop on Google Code or SourceForge just for the SVN support. Please get this in asap so we can use SVN natively. TFS is just too slow and obtrusive for community projects.

jwanagel wrote Dec 18, 2007 at 9:00 PM

We're expecting to deploy an SVNBridge server sometime in January.

spintz wrote Jan 1, 2008 at 4:42 PM

I've already left codeplex and am sticking with Sourceforge. Why wait a year for support for something that's already existed for years elsewhere?

jwanagel wrote Jan 15, 2008 at 10:12 PM

I received word that the hardware we've ordered for running our SvnBridge server won't be delivered and racked in the data center before the end of January. So unfortunately we won't be able to deploy an SvnBridge server until February.

quantum00 wrote Jan 23, 2008 at 5:55 PM

Personally, I will only use Subversion. Definitely a deal breaker. SVN isn't simply a "source control" system, it's a light-weight distributed transactional file system that allows VERY efficient viewing via a web browser. I don't always want to download, not can I always download (using a friends machine for the day to review code)! Without SVN, there's no chance any of my projects will ever see CodePlex. Many of my projects are 90% JavaScript with 10% .NET-- my JavaScript editor is notepad2, therefore SVN with TortoiseSVN and it's explorer integration is perfect for me.

quantum00 wrote Jan 23, 2008 at 5:57 PM

And BTW: SvnBridge is NOT SVN support! That thing crashes every single time I try to view a project in my web browser.

Qwertie wrote May 19, 2008 at 3:52 PM

I was thinking of switching from SourceForge to CodePlex because SF has such poor site navigation, poor help documents, is sometimes slow and just isn't pretty... but certainly I wouldn't switch unless I could use SVN here. Is this SvnBridge is really good enough to replace real SVN?

jwanagel wrote May 19, 2008 at 11:11 PM

People generally seem quite happy with the experience using SvnBridge, particularly with the v2 version. I recommend you give it a shot and see what you think, but I think you'll find it is good enough to make it worthwhile.

jwhitehorn wrote Jul 2, 2008 at 3:36 PM

I too agree that CodePlex needs TRUE subversion support if it is going to be taken seriously. I've even moved my projects from CodePlex to Google Code primarily because of Subversion. Having Subversion gives an open source project a lot of additional exposure through sites like Ohloh, Koders, etc. It preciously that visibility that raises public awareness of the projects and gets people involved both at a user level and at a developer level.

bsimser wrote Jul 17, 2008 at 7:33 PM

What's the status update of this feature? The last comment from the team I saw was that a server was coming in January. It's now the middle of July.

mkroll wrote Aug 19, 2008 at 9:17 AM

@jwanagel: I'm not happy with SvnBridge at all. Not only that it's unbelievable slow and created over 500,000 files on my NTFS (which took me about half an hour to remove them), it also does not support "svn diff" which is in my opinion one of the most important features of a versioning system. Now I have to check out all versions I want to compare manually and run a recursive diff on it... Just unusable, especially because of the non-existing speed.
Also the svn:eol-style property does not seem to work correctly. Another team member not using an svn client had many files with mixed line endings. Doesn't TFS have any support for managing eol-style??

cartershanklin wrote Sep 10, 2008 at 1:42 AM

Two thumbs down on SVNBridge (but that's only because I don't have 3). This is a must-have feature.