[TxMt] BundleForge: time to start?

[Sebastian Graessl]

The point why i (and i think Allan would agree) is to make
contributing Bundles as easy as possible and not force people to learn
Subversion.
Another thing why i want to do something like that to make the
GetBundle work with Bundles outside the Official Repository.

2006/12/8, Rob McBroom <textmate at skurfer.com>:
> 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.
>
>
>
>
> ______________________________________________________________________
> For new threads USE THIS: textmate at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
> http://lists.macromates.com/mailman/listinfo/textmate
>