Hi, On Wed, Jun 25, 2008 at 12:36:03AM -0000, David Jeske wrote: > The purpose of this mechanism is to host a distributed source repository in a > world where most most developer contributors are behind firewalls and do not > have access to, or do not want to configure a unix server, ftp, or ssh to > possibly contribute to a project. The model of allowing less-authoritative > developers to make their changes available for more-authoritative users to pull > is accepted as superior. However, no users are assumed to be authoritative over > each-other, or an entire tree, and many users should have authority only to > supply new deltas to their own branches. The ability to handle emailed patches > is an asset, but is deemed too manual for this need. BTW, have you read about git-bundle(1)? > design assumptions: > > - all developers are firewalled and can not be "pulled" from directly. > - there can be one or more well-connected servers which all users can access. > - .. but which they cannot have ssh, ftp, or other dangerous access to > - .. and whose protocol should be layered on http(s) Please note that we support pushing using the HTTP DAV extensions. It seems to be only rarely used in practice though, since developers seem to either work at sane companies, are tunneling through the firewalls or the firewalls are adjusted if this is required for development of their day-job applications. There are some cases where this is useful, but I don't tihnk they are very numerous (in practicular, I've had more requests (about three?) for git-cvsserver than for HTTP DAV (zero to one?) at repo.or.cz). Do _you_ have any real large-scale scenario where this is an actual issue? > - there is a shared namespace for branches, and tags > - .. users are not-trusted to change the branches or tags of other users > - .. only certain users are trusted to change the shared origin branches > - .. also allow directory ACLS on shared branch commits > - all their DAGs should be in a single repository for space efficiency > - users generally want to follow well-named branches > - .. will be free to follow any branch, and pull changes from any branch Of course, if pushing through the DAV extensions this can get hairy; if you allow push access for users, you better trust them since they can touch the objects database. If you don't care about possible DoS attack vectors, I assume you could configure refs permissions for various users using some fancy Apache configuration. As previously noted though, I believe the space efficiency is not an issue in real world. Are you familiar with Git's alternates? In a Git repository, you can specify alternate locations for searching objects, so you can create a "sub-repository" for each user, where an alternate is set up pointing to the object database of the main project repository. Then, the bulk of the objects will be in the main repository and the sub-repositories will carry only tiny amount of objects specific to the local development of the given person. This is exactly how (and large reason of why) the repo.or.cz forks are set up, by the way. -- Petr "Pasky" Baudis The last good thing written in C++ was the Pachelbel Canon. -- J. Olson -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
