Slashdot Mirror
Distributed Development, with Karl Fogel
phyjcowl writes "Karl Fogel is a founding developer of the Subversion project. In the following interview he covers social aspects of coordinating developers as well as the difficulties and advantages of managing an open source, distributed development project. Karl explains the inception of the Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it."
First post
f
p
!
fail!
omg gaping gape gaping ooomg!1oneone
Anyone have another link?
Tristan Yates
Interview with Karl Fogel of Subversion and CollabNet
J. Chalifour - July 27, 2005
Introduction
Karl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development...
Access to this resource
requires TEC Membership (it's FREE).
WAY TO GO, GUYS!
http://www.thebricktestament.com/the_law/when_to_
Nice of me to state the obvious there in the subject line. :-)
The article requires some non-negligble amount of registration, so I will simply forego all that and give my impressions of my experience with distributed development.
DON'T DO IT!!
I believe that was Sam Kinison's advice on a host of things.
The biggest problem with distributed development is lack of coordination between members. Especially on public Open Source projects where members may not show up on time or even at all, and there really isn't any way to force them to do so.
This means that the biggest challenge in running a successful project is to staff it with sufficiently trustworthy engineers who see the success of the project as a common goal. This isn't unlike typical closed source project management except that you can't really fire anyone.
I've found that once you've got a critical mass of dependable engineers working on the project, that much of the development takes care of itself. Active mailing lists are mandatory, as are clear objectives. But if you don't have people you can trust submitting code, then you're basically doing it all by yourself.
Jesus saved me from my past. He can save you as well.
Ideas of different people come together to form this Massive Distributedly Developed Project.
What happens when a project becomes both disturbing and subverted? Go figure.
Do the editors not actually visit the links provided with the submissions?
I think they do, and I think this is another one of those slashvertisements that people get punished around here for suggesting they even exist.
I was actually looking forward to reading something from one of the svn devs. What a fucking waste of time.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
This article requires registration.
Somehow, the Slashdot editors still think it's cool to post stories to registration-required websites.
Great way to promote Subversion, an otherwise killer tool.
Mod me troll, it's obvious that I am.
I registered an account -- read the article if you want.
login: fuckhead
password: fuckhead
email: fuckhead@mailnator.com
http://www.thebricktestament.com/the_law/when_to_
I've made it! Try huhuha/hehe.
Interview with Karl Fogel of Subversion and CollabNet
... We were trying to replace CVS.
J. Chalifour - July 27, 2005
1. Introduction
2. The role of developers
3. Social aspects of the development community
Part I | Part II | Part III | Part IV
Related Book
Introduction
Karl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development.
Subversion is a type of software configuration management (SCM) tool known as a version control system. These types of tools are important toward letting developers collaborate on software projects. Subversion is part of the tigris.org community's focus on building collaborative software development tools. CollabNet provides enterprises with distributed software development solutions. It's used by companies such as Sun Microsystems, HP, and Barclays Global Investors to help coordinate development teams spread out around the world.
Part III of the Concerted Disruption, Climb Aboard series.
We started Subversion about five years ago, and I think it is a little bit different from a lot of open source projects because we started with the goal of replacing a specific piece of open source software
You had a good reference point.
We had a great reference point and also that saved us from a lot of arguments about what should and shouldn't be in our first release. We could say that if it's in CVS it should be in our 1.0 version, if it's not in CVS it doesn't need to be. There was an inherent controversy reduction substance in our projects--at least before 1.0. Now we get into all those discussions that we put off. But we have a foundation/relationship already built with all these people that makes it a lot easier to do that because they all worked together to get to 1.0.
As to how we got those developers. The numbers we have right now are roughly thirty full committers--people who can commit anywhere in the source code, thirty partial committers--people that just do documentation fixes, fix support scripts, or something like that but do not have commit rights in all the code. Of those thirty full committers, I'd say roughly fifteen are really active on a day-to-day basis. You get some others that come flying in like Han Solo every now and then--they fix a bug and then they go out and you don't hear from them for a few months.
The way we founded it was mainly word-of-mouth. We knew the CVS space pretty well, we started contacting those people, they talked to their friends, and pretty soon people just showed up. We actually held physical, open-to-the-public design meetings when we began the project in San Francisco. Some of those people are still with the project today. But you know, one of best committers is in Slovenia and he certainly didn't come to those design meetings. But we wouldn't be where we are without him.
Could you please clarify your role in the project?
I guess you could call it, founding developer. CollabNet only employs somewhere between three and four of those committers. We don't all work 100 percent on Subversion all the time. Somewhere between three and four is accurate. My role was mainly--you know I had a lot of experience working with open source projects before, and in particular with CVS, which helped to get me involved with version control--it was sort of to set the tone at the beginning of the project--a CollabNet-to-developer liaison when necessary, although there haven't been that many conflicts, we haven't n
http://www.thebricktestament.com/the_law/when_to_
http://www.bugmenot.com/view.php?url=http%3A%2F%2F www.technologyevaluation.com
"Who says nothing is impossible? Some people do it every day!" - Alfred E. Neuman
Introduction
... We were trying to replace CVS.
Karl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development.
Subversion is a type of software configuration management (SCM) tool known as a version control system. These types of tools are important toward letting developers collaborate on software projects. Subversion is part of the tigris.org community's focus on building collaborative software development tools. CollabNet provides enterprises with distributed software development solutions. It's used by companies such as Sun Microsystems, HP, and Barclays Global Investors to help coordinate development teams spread out around the world.
Part III of the Concerted Disruption, Climb Aboard series.
We started Subversion about five years ago, and I think it is a little bit different from a lot of open source projects because we started with the goal of replacing a specific piece of open source software
You had a good reference point.
We had a great reference point and also that saved us from a lot of arguments about what should and shouldn't be in our first release. We could say that if it's in CVS it should be in our 1.0 version, if it's not in CVS it doesn't need to be. There was an inherent controversy reduction substance in our projects--at least before 1.0. Now we get into all those discussions that we put off. But we have a foundation/relationship already built with all these people that makes it a lot easier to do that because they all worked together to get to 1.0.
As to how we got those developers. The numbers we have right now are roughly thirty full committers--people who can commit anywhere in the source code, thirty partial committers--people that just do documentation fixes, fix support scripts, or something like that but do not have commit rights in all the code. Of those thirty full committers, I'd say roughly fifteen are really active on a day-to-day basis. You get some others that come flying in like Han Solo every now and then--they fix a bug and then they go out and you don't hear from them for a few months.
The way we founded it was mainly word-of-mouth. We knew the CVS space pretty well, we started contacting those people, they talked to their friends, and pretty soon people just showed up. We actually held physical, open-to-the-public design meetings when we began the project in San Francisco. Some of those people are still with the project today. But you know, one of best committers is in Slovenia and he certainly didn't come to those design meetings. But we wouldn't be where we are without him.
Could you please clarify your role in the project?
I guess you could call it, founding developer. CollabNet only employs somewhere between three and four of those committers. We don't all work 100 percent on Subversion all the time. Somewhere between three and four is accurate. My role was mainly--you know I had a lot of experience working with open source projects before, and in particular with CVS, which helped to get me involved with version control--it was sort of to set the tone at the beginning of the project--a CollabNet-to-developer liaison when necessary, although there haven't been that many conflicts, we haven't needed a liaison that much. My role is also to write code.
It's hard to put my finger on it exactly but when you have a bunch of volunteers, the main currency that's going on is attention. If one of them does something, does so
I would think everyone has the bugmenot firefox extension installed by now. The first try worked for me.
Hot Karl
Wow nice way to slip it past the mods.
Firstly, the proxy support. One of the big benefits of Subversion is that it can use HTTP to talk to the server. So one would hope that the network connection set up with Subversion is easier than CVS, right?
Well, not at all, I found.
First, as a Windows program, it should be using the platform proxy setting (the one you set through IE's connection setting dialog.) It's a fairly sophisticated mechanism that covers wide range of use cases. It's also reasonably easy to use from programs --- you just need to use WinInet library instead of the socket library. Or as an Unix program, you can take $http_proxy variable, which seems to be the de-facto standard of setting up a proxy. Instead, Subversion decided to invent its own way of setting proxy information. This makes it really painful to switch one network configuration to another.
Second problem. Network connection problems are one of the most common problems, because there are just so many things that can go wrong. So a program should be able to help users diagnose the problem. With CVS, you can use the -t option to trace the network access of the CVS program. You can see which host/port it's connecting to (if it's pserver), or you can see how CVS spawns the connect program (if it's ext.)
Subversion doesn't have any such option (in fact it doesn't seem to have any global option, so I might be missing something.) When there are so many places you can set network configuration (~/.subversion, registry, ...) this is just poor craftsmanship. If Subversion had a trace option to cause it to print where it's loading proxy information, how it's connecting, and what repsonse it's getting, it would save a lot of time for many users.
Third problem. In theory, HTTP-based connection support would have improved the connectivity. But in practice, because Subversion decided to use the WebDAV protocol, it uses many HTTP methods (like PROPFIND) that are often not allowed by a proxy server. A simple Google search reveals how pervasive this problem is. While I'm sure the use of WebDAV makes some technical sense, it would have been a lot easier to us users if it just uses a standard GET or POST method coupled with the Subversion-Action header or something (guess SOAP-Action header is done for a reason!)
Fouth problem. Of all the modern programming languages you can choose to implement Subversion with, they chose C. I mean C, the least productive programming language of all kind, that only second to the assembly language. Sure, it's necessary sometimes, like when you are writing a kernel, or a really high-performance computing. But Subversion is neither.
Users would have been served much better if the time of Subversion developers are spent on improving the tool itself, instead of fixing string manipulation bugs, tracking down core dumps, and etc. I really don't understand why they didn't pick Python, Ruby, or even Java. It makes Subversion runs on more platforms, it improves the productivity of developers.
You see, none of those are critical to the architecture of Subversion or anything. It's just the rough edges that you need to smooth out. It's really nothing but a lack of craftsmanship to be unable to remove this many issues after so many years of development (I hit all those problems within an hour.)
Well, now that I said all I wanted to say, at least I feel much better!
Login and Password: dontbugme
God that's annoying.
--- = page break
... We were trying to replace CVS.
I didn't format this because I'm tired and it's bed time. Sorry.
-------------
Carl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development.
Subversion is a type of software configuration management (SCM) tool known as a version control system. These types of tools are important toward letting developers collaborate on software projects. Subversion is part of the tigris.org community's focus on building collaborative software development tools. CollabNet provides enterprises with distributed software development solutions. It's used by companies such as Sun Microsystems, HP, and Barclays Global Investors to help coordinate development teams spread out around the world.
Part III of the Concerted Disruption, Climb Aboard series.
We started Subversion about five years ago, and I think it is a little bit different from a lot of open source projects because we started with the goal of replacing a specific piece of open source software
You had a good reference point.
We had a great reference point and also that saved us from a lot of arguments about what should and shouldn't be in our first release. We could say that if it's in CVS it should be in our 1.0 version, if it's not in CVS it doesn't need to be. There was an inherent controversy reduction substance in our projects--at least before 1.0. Now we get into all those discussions that we put off. But we have a foundation/relationship already built with all these people that makes it a lot easier to do that because they all worked together to get to 1.0.
As to how we got those developers. The numbers we have right now are roughly thirty full committers--people who can commit anywhere in the source code, thirty partial committers--people that just do documentation fixes, fix support scripts, or something like that but do not have commit rights in all the code. Of those thirty full committers, I'd say roughly fifteen are really active on a day-to-day basis. You get some others that come flying in like Han Solo every now and then--they fix a bug and then they go out and you don't hear from them for a few months.
The way we founded it was mainly word-of-mouth. We knew the CVS space pretty well, we started contacting those people, they talked to their friends, and pretty soon people just showed up. We actually held physical, open-to-the-public design meetings when we began the project in San Francisco. Some of those people are still with the project today. But you know, one of best committers is in Slovenia and he certainly didn't come to those design meetings. But we wouldn't be where we are without him.
---
Could you please clarify your role in the project?
I guess you could call it, founding developer. CollabNet only employs somewhere between three and four of those committers. We don't all work 100 percent on Subversion all the time. Somewhere between three and four is accurate. My role was mainly--you know I had a lot of experience working with open source projects before, and in particular with CVS, which helped to get me involved with version control--it was sort of to set the tone at the beginning of the project--a CollabNet-to-developer liaison when necessary, although there haven't been that many conflicts, we haven't needed a liaison that much. My role is also to write code.
It's hard to put my finger on it exactly but when you have a bunch of volunteers, the main curr
Introduction
... We were trying to replace CVS.
Karl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development.
Subversion is a type of software configuration management (SCM) tool known as a version control system. These types of tools are important toward letting developers collaborate on software projects. Subversion is part of the tigris.org community's focus on building collaborative software development tools. CollabNet provides enterprises with distributed software development solutions. It's used by companies such as Sun Microsystems, HP, and Barclays Global Investors to help coordinate development teams spread out around the world.
Part III of the Concerted Disruption, Climb Aboard series.
We started Subversion about five years ago, and I think it is a little bit different from a lot of open source projects because we started with the goal of replacing a specific piece of open source software
You had a good reference point.
We had a great reference point and also that saved us from a lot of arguments about what should and shouldn't be in our first release. We could say that if it's in CVS it should be in our 1.0 version, if it's not in CVS it doesn't need to be. There was an inherent controversy reduction substance in our projects--at least before 1.0. Now we get into all those discussions that we put off. But we have a foundation/relationship already built with all these people that makes it a lot easier to do that because they all worked together to get to 1.0.
As to how we got those developers. The numbers we have right now are roughly thirty full committers--people who can commit anywhere in the source code, thirty partial committers--people that just do documentation fixes, fix support scripts, or something like that but do not have commit rights in all the code. Of those thirty full committers, I'd say roughly fifteen are really active on a day-to-day basis. You get some others that come flying in like Han Solo every now and then--they fix a bug and then they go out and you don't hear from them for a few months.
The way we founded it was mainly word-of-mouth. We knew the CVS space pretty well, we started contacting those people, they talked to their friends, and pretty soon people just showed up. We actually held physical, open-to-the-public design meetings when we began the project in San Francisco. Some of those people are still with the project today. But you know, one of best committers is in Slovenia and he certainly didn't come to those design meetings. But we wouldn't be where we are without him.
Could you please clarify your role in the project?
I guess you could call it, founding developer. CollabNet only employs somewhere between three and four of those committers. We don't all work 100 percent on Subversion all the time. Somewhere between three and four is accurate. My role was mainly--you know I had a lot of experience working with open source projects before, and in particular with CVS, which helped to get me involved with version control--it was sort of to set the tone at the beginning of the project--a CollabNet-to-developer liaison when necessary, although there haven't been that many conflicts, we haven't needed a liaison that much. My role is also to write code.
It's hard to put my finger on it exactly but when you have a bunch of volunteers, the main currency that's going on is attention. If one of them does something, does somebody notice? They're going to do
I prefer doing my development - distributed or otherwise - with Python. I've never quite grasped the syntax of Karl Fogel.
flaimbait by Karl Fogel, internet troll
location:Chalifour - July 27, 2005
1. Bragging rights
2. Bend over developers
3. programmers have no Social life
Part I | Part II | Part III | Part IV
Related Book
Introduction
Karl Fogel made up a dot com, and got VC to pay his salary. Karl need more cash for his next porche^H^H^H^H^HSubversion project, what does it take to get VCs money now? How to keep the cash coming -- submit article to slashdot. Karl sees a lot of dough coming his way conning such a community of suckers, Noobs can't use a command prompt, so shell out the dough to buy our shit.
Subversion is rip off of CVS, which you can download free. It's important you buy subversion, cause daddy needs a new porche. Subversion is part of the 2005 dot com bubble. CollabNet screws corporate clients to install their CVS. Suckers include Sun Microsystems, HP, and Barclays Global Investors But that's not good enough, we need to scre the whole world over, that means You Linus Torvalds!
Part III of the Concerted Disruption, Climb Aboard the take it up the ass series.
We started Subversion about five years ago, by stealing the CVS source tree, obfuscating it, and patenting crap related to it.
it felt good.
our first release was a total knock off, we didn't even code it. Since we stole the codebase, we only had the features of cvs, and we couldn't implement anything new. people on the internet got mad--until we ofuscated the code. We silenced/paid off anyone concerend. they're sleeping with the fishes or will never work in this town again.
We gots us 60 suckers who do all the programming for free, plus a few fly by nights, all from trolling slashduh and boy will we make money off this.
We suckered the open source community, they thought we weren't gonna patent their code hahah suckers. The suckers brought in more suckers. We actually let the sucker VCs and some of the sucker code monkeys visit us in San Francisco. Some of them still don't have a clue about how hard we assraped them. Our code has a backdoor installed by a Slovenian coder sho does the bulk of the work 'for free'.
---
This is too damn long, but this is a pretty damn good translation... cuts straight through the bull.
https://www.gnu.org/philosophy/free-sw.html
Does anyone have good/bad things to say about Darcs
It is written in a purely functional language. The stuff is rooted in a theory of patches.
Does this stuff actually work? Subversion seems like a reworking of CVS (minus the warts). Darcs seems like a different animal.
http://www.thebricktestament.com/the_law/when_to_
Jesus, the moderators who sent that to +5 should just be shot in the head. Now.
Just for starters, HTTP plus WebDAV is incompatible with your fucking proxy server dickwad. svn ignored your proxy settings because they wouldn't have fucking worked. I'm sorry you are disappointed that they tried to play well with the Standard protocol for versioning stuff. They must've been total idiots to not do things which you thought were a good idea after thinking about them for ten minutes. Cause you know, you think of way hella smarter things in ten minutes that the svn team ever could have thought of in the last five years of actual work doing the design.
We use SubVersion at our company for well over two years now, and since then I've been subscribed to the SubVersion user and developer mailing lists.
I find the SubVersion project a very interesting project. What really makes this project shine is the development quality. By this I mean:
I've seen a few OpenSource projects by now, even was co-leader of a very small, now long abandoned project and thus am really impressed by the way development is done in the SubVersion project.
I really, really wish that I'll have the opportunity to work on a commercial project that comes halfway to the code quality of the SubVersion project. I'm a professional programmer for just about four years now but have already worked on some big industrial projects (industrial robots, lasers). Still I have yet to see a commercial development project where not some really dumb programmers can constantly screw the project, check code in that doesn't compile, doesn't follow the coding style or is simply of low quality. I see code that almost no OpenSource project would accept on a daily basis. And this code is produced by people that are highly paid and sometimes have years of experience (but still should visit a "Coding 101" course !).
Very often I think, "Now if this were an OpenSource project that code would have been rejected and the programmer would have been forced to correct it and do better next time." Unfortunately this will stay a dream, and thus I fear I'll never see a commercial project with code quality that rivals that of SubVersion.
Subversion is an open source source code management tool. It's distributed under the BSD license, I think. It has nothing to do with BitKeeper or the Linux kernel source code management debacle.
Slashdot Declaration of Independence
When other tech companies severely take advantage of their customers, dismissing
any notion of customer service or satisfaction, they are no doubt subject to criticism by
the ever vigilant masses of Slashdot. Why should Slashdot itself be any different?
We must remember that slashdot makes money off subscriptions and ad revenues.
There is no altruistic motivation behind their actions, and as such, the Slashdot editors
are not so much editors as they are salesman.
In addition, we must remember that Slashdot is NOT a legitimate journalistic endeavor.
These so-called editors did not attend journalism school, nor is there a centralized forum
to air grievances done on the site. To the slashdot editors, their words are final, and cannot
be criticized.
We put forth three major grievances we have with Slashdot and its editors.
1. Complete lack of dupe checking and article checking:
Imagine a newspaper that routinely prints stories from months, weeks and even days
before. Image the same newspaper placing all import on the headline, rather than the
content. Surely this newspaper would not last long. If the readers would write in to the
editor to complain, surely they wouldn'thave chastised by the editor.
Yet, as we are all aware of, this is the biggest problem facing slashdot. Although there
is no editorial section in which we may submit letters, we have the option to directly
emailing the editors. What happens when we do? We are scolded and our opinions
are labeled as hate mail.
http://www.anti-slash.org/injustices/CmdrTaco/taco _dupe_lash_out/
2. Increased commercialization behind articles:
Many recent articles seem to be advertisement for products, and not really newsworthy.
Other articles (including the recent "discovery" of month old google products) try to get Slashdot in
good graces with particular organizations.
Here are more examples of such "Slash-vertisement:"
http://www.anti-slash.org/injustices/other/extreme tech_slashvertisement/
3. Blatant editor errors:
The role of an editor is to oversee the final content of text before it goes into publication. That, believe
it or not, includes checking minor errors in HTML and spelling, in addition to larger errors.
There are several instances of items just not being checked:
http://books.slashdot.org/comments.pl?sid=157102&c id=13170467
http://developers.slashdot.org/comments.pl?sid=157 209&cid=13177798
http://science.slashdot.org/comments.pl?sid=157125 &cid=13172520
http://games.slashdot.org/comments.pl?sid=156961&c id=13159282
Where as grievance one details the question of "newsworthiness" of an article, grievance three
points out instances where article and summary do not agree, in addition to the smaller problems
of spell checking etc.
Resolution:
We do not have to stand for this lack of respect toward the customer. There are alternatives to slashdot.
http://www.digg.com/ has had good reviews from the slashdot crowd.
If leaving slashdot all together seems too extremist you can start demanding better treatment from the
editors. Demand a public forum where we can discuss our issues with slashdot, and see that they
are resolved.
Demand more from this money-making machine! You are all its customers. You
or are /. readers being .. er.. overzealously helpful today? I reckon I've read the "Full article Text", and obtained logon details for TFA about 3,427 times already :S
/. editor didn't bother to click a link.. /.'s standards seem to be dropping to new record levels every day.. :S
All becase a
Why is this moderated funny? It is actually informative. :) the registration works!
I spent a few months with Subversion. I tried what was being hyped by you and your pals as the greatest thing ever. These were real problems I had. Sorry you don't like it, but that's the way it is. There has been no indication of a change in attitude with regards to better interopability with Windows, and a simple scaffolding blows up with the current version, so I think clearly the issue has not been dealt with sufficiently.
As for for your ethereal obsession with Microsoft... seek help.
added your subscribtion to bugmenot.com[/]
first line: flaimbait by Karl Fogel, internet troll
this is NOT informative. maybe funny,if you are italian or braindead, but NOT informative.
If you want revision control that's flexible network-wise, it doesn't get much better than Arch. You can use any filesystem for the repository that your box can see. NFS, FTP, HTTP, SCP, it's all good.
Want Python? Use Cannonical's implementation of the Arch protocol, Bazaar. It's got nummy Python goodness baked in, along with better support for digitally signed repositories (via GPG).
$DEITY help you if you want to use either on Win32, however. The Arch protocol requires both a real filesystem, and an OS that can use case-sensitive semantics properly.
What does this button d$#%* NO CARRIER
Boy, you are just really bitter about the BitKeeper thing aren't you? This isn't BitKeeper and it doesn't have anything to do with those guys.
If you find distributed development with SVN difficult, why not try Arch :-D
So how did they communicate? Via unit tests. If Dave commits code that breaks something, he gets a unit test in the mail. When the test works again, he knows that he's fixed the problem.
Pretty interesting solution!
Agile Artisans
you are insulting the manhood of all programmers! prepare for a duel!
with the Number YOU LOVED THAT its corpse turned
I can see where distributed development can work well when a project is an open source labor of love. However, I don't see it working well for purely commercial or in-house proprietary software. In my experience, those commercial developers who insist on working remotely are disinterested mercenaries that only see their employer as a means to their preferred remote lifestyle. I admire folks who know what they want, in terms of where they live, but I don't think it's in the best interests of a business to fund the lifestyle of someone who want to live in a rural resort community rather than being a full participant who comes to the office each day.
Yeah it took me a while to figure out why the http_proxy env variable didn't work. Then, you need to ask your sysadmin (if that's not you) to open up the ports (like for squid)
Now if you run your own Squid, but are limited to ssh, you can still make Subversion work.
Years back, when I was first learning CVS, there was the Cederqvist and then there were the FREE chapters of Karl's CVS book at redbean.
While the Cederqvist may have been great, Karl's free chapters saved me. They described things simply and elegantly. I found them so useful that I would set up new development machines with a browser bookmark to redbean. Any time a CVS question popped up, I could answer it quickly, but I could always say "That's the short version, but if you want to know more, look at Karl Fogel's book."
The man is the cat's pyjamas, imho.
.. pa-ra-bo-la, pa-ra-bo-la, 2 pi R, 2 pi R, where's your latus rectum, where's your latus rectum, 2 pi R