Server version of SvnBridge

Jul 24, 2007 at 4:34 AM
We're making good progress on getting to our "v1" of SvnBridge, with the next step after that is the server version.

Since we plan to run the server version of SvnBridge on CodePlex, does anyone have any thoughts on how they think it should be accessed? Some potential ideas:

  •<projectname> (mirror our TFS servers so have an svn01, svn02, etc)
  •<projectname> (have a single URL for all TFS servers)
  • http://<projectname>
  • Other?
Jul 24, 2007 at 4:54 AM

It's consistent with other hosting sites. Consistency is good here, since if you are familiar with the other sites, you'll get familiar with CodePlex that much more quickly.
Jul 24, 2007 at 3:32 PM
I vote for codeplex consistancy.<projectname>
Jul 24, 2007 at 4:08 PM

z2bass wrote:
I vote for codeplex consistancy.<projectname>

That could be changed too. In fact, it's a work item request.

I never did like the tfsXX since I have projects on different servers, and I have to keep track of it. There's a work item request for this too. Let's not promulgate the difficulty of managing multiple projects.
Jul 24, 2007 at 4:36 PM
Well, there's a reason for tfsXX (physically separate boxes). I wouldn't necessarily like svnXX, personally. I think I'd rather have<projectname> because it's more consistent with CodePlex (i.e., we don't do for projects, nor should we for svn).

Jul 24, 2007 at 6:31 PM
I understand the reason for tfsXX, but it's a leaky abstraction. It could be different... hiding it under a CNAME or rewrite would make life easier for users.

If you abstracted the tfsXX name, doing the same for other extensions, like SVN bridge and whatever the future brings, would allow more flexibility and be less brittle. It's basically hiding your internals.

Another benefit for ease of use with the <projectname><service> format is that ordering and finding project URLs is more efficient (since they sort by project name first). Typing the project name in your browser address bar is a nice way to find the projects you've been to.
Jul 26, 2007 at 5:59 PM
The tfsXX convention might be a leaky abstraction, but since Team Explorer doesn't let you connect to multiple servers simultaneously, using <projectname> instead of tfsXX would alway force developers of multiple projects to switch servers all the time. At least now you might get lucky and have all your projects on one tfsXX server. :-)
Jul 26, 2007 at 8:20 PM
But how does the CodePlex client handle the anonymous checkout case without needing to specify the server? It has to keep a mapping somewhere. Couldn't <projectname> do the same thing?
Jul 27, 2007 at 10:51 PM
It could but that wouldn't help the problem when using Team Explorer. If you have and then because Team Explorer only allows you to be connected to one server at a time, you would have to disconnect from to connect to However, if both project1 and project2 are on the same TFS server then you can connect to and access both project1 and project2 simultaneously.
Jul 28, 2007 at 5:58 AM
Ah, it seems you are optimizing for Team Explorer. I'd like to encourage you to optimize for Subversion. On an open source project, I suspect it is going to be a much stronger usage base. That, and we're only talking about an edge case for Team Explorer. You could probably right now run a report to quantify how much of an impact it would be, vs. a longer term segmenting of project namespace.

The real question, beyond the technological particulars, I think, is what are the differentiating characteristics of http://<projectname><service> vs. http://<service><projectname>, and are these differences significantly more beneficial one way vs. the other. For TFS on an intranet, this might not matter, but for CodePlex, I think it does.

After some thought, it appears to me that the three most distinguishing characteristics of <project><service> are 1) sortability by project for user agents, 2) redirectability at the DNS and the URL level, allowing more flexibility in both hosting and occasionally connected user agent scenarios, and 3) a mindset that CodePlex is for hosting projects first and foremost.

I'll admit it's not immediately and overwhelmingly clear to me, but I think these are compelling enough reasons to implement <project> Both SourceForge and Google Hosting does it this way... and there is an appeal to having a subdomain just for the project. Windows Live spaces switched from<spacename> to <spacename> and there was some indescribable satisfaction when they did this. It was like my space was distinguished enough to get a subdomain. It also was nice to have it come up when I typed it's name in the browser instead of having to type and having to wade through the long list. I can't measure this (since the stats on Windows Spaces are just awful), but I think I started to get more hits, too - perhaps the page rank got boosted a bit in the search engines due to the subdomain status.

I think that, due to the probably underestimated effect of benefit 3 above, there would be a general feeling of satisfaction that would come from the CodePlex user community if <project> was implemented, especially if over the limitations of the technology on which it is based. If the desire for anonymous access and Subversion taught us anything, it was this. Perhaps try this: ask around, but not just on this discussion group. Write the project owners and solicit their feedback individually. They'd no doubt be quite encouraged to have the CodePlex developers be so engaging. And, maybe we'd all get a surprise on what the community in general wants.
Jan 15, 2008 at 2:07 AM
We're going to be deploying an SvnBridge server soon and we're thinking we'll use the following URL format: https://<projectname>

Does that work for people?
Jan 16, 2008 at 5:56 AM
Hi - I'd be interested to know how you set up SvnBridge in IIS6...

May 4, 2008 at 1:02 PM

jwanagel wrote:
We're going to be deploying an SvnBridge server soon

Any update on when the server will be deployed?

May 5, 2008 at 2:50 PM

kolchak wrote:
Hi - I'd be interested to know how you set up SvnBridge in IIS6...