On Dec 8, 2006, at 10:52 AM, thomas Aylott wrote:
Agreed. How do you suppose such a thing should work?
I like that it's Subversion based now. I ask myself: What do we want that we don't currently have?
The main thing that comes to mind (which was recently discussed on this list) is some sort of description and/or documentation for each available bundle. I also would advocate some additional meta-data on top of that. For example, it would be nice to have attributes that allow you to see…
* Bundles that are considered obsolete * Bundles that the developer considers to be a work in progress and possibly not ready for prime time. "BETA", for lack of a better word. * Bundles that are included with TextMate by default (and of these, perhaps even show which have been updated since the last TextMate release?).
It might also be nice to know who "works on" each bundle, but I'm wondering if we should purposely not make that information available to those without "commit" access. The reason being that if you don't know who does a particular bundle and are forced to take your question to the entire list, there are a lot more eyes on the problem and we'll probably end up with a more elegant solution in the end.
I realize there a folks with an aversion to Subversion :), so should we do something to accommodate them or make them get with the program? I was thinking we could have a post-commit hook that would tar up a working copy of each bundle as it's updated. And maybe we strip out the `.svn` directories first or maybe we don't. Seems to me that if it's checked out a certain way and we leave the `.svn` dirs in place, the person who downloads the tarball version could run `svn update` on it at some later point if they wanted to. This would of course be unrealistic if we stick with one huge repository for everything (see below).
I'd be curious to hear what those with commit access think is missing.
I like how the official repo is a single svn server. But if bundleForge is only a single repo, then everyone has access to all of of the bundles.
From what I know of Subversion, a single server with multiple repositories could be "transparent" to all the clients doing checkouts, but it could be an access control nightmare depending on how fine-grained you want to make it. Is there a reason that there's currently only one repository?
--- Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.