- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, we have to live on this hairy edge of is it a floor wax or is it a dessert topping. Like other "open source" projects that haveboth a publicly accessible and commercial side (see mysql or Qt)we have multiple audiences with different requirements, which forces us to keep control of the master copy and put contributors through all kinds of hoopsjust to propose changes. And we isolate our engineers from those proposals until we can at least do a gross check that they don't contain code borrowed from elsewhere. Today there's been a lot of dialog kicking around internally about how far we can go, and maybe someday you might find something come of it, but I fearthe most you could hope for is a read-only repository, certainly not something you could actually check code into.
We aredefinitely sold on the open source model for the development of TBB, which has already proven its worth. We have several ports to other OSes that we might not have had otherwise and the extra eyes on our code have improved its quality. So to aid our internal dialog, let me turn the question around: would you derive any benefit from having a respository even though it was read-only?I don't thinkanswering in the affirmative would be compelling, but it would add credence to the argument.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"Would you derive any benefit from having a respository even though it was read-only?"Oh yeah, totally. Nearly all public repositories are effectively read-only to me, since I'm not a contributor to their projects, so being more restrictive with your commit access would have very little effect. The benefits I see are:
- I could sync, even when your downloads page is broken, like last weekend. ;)
- I could use standard version control features to maintain patches or even development branches, even when you check in patches. Using diff and patch to move changes between versions is outdated enough that I'm awkward doing it.
- I could easily see when a new feature went in and what needed to change to add it by looking through the revision history or blame output, instead of having to look through the CHANGES file and then diff the relevant two releases.
- You'd benefit too: the diff output from svn tells you exactly which revision it's against, and I believe the DVCSs have even more advanced ways of mailing patches around. You probably would still get manual patches that forgot to say what they were diffing against, but anyone using the repository wouldn't have to remember, and would probably be able to give you more up to date patches.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page