{"thread":{"id":"14145","subject":"Re: policy and mechanism for less-connected clients","startedAt":"2008-06-25T14:03:45Z","lastAt":"2008-06-25T14:03:45Z","messageCount":1,"participants":["Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"81119","messageId":"20080625140345.GA12567@machine.or.cz","threadId":"14145","inReplyTo":null,"subject":"Re: policy and mechanism for less-connected clients","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-06-25T14:03:45Z","receivedAt":"2008-06-25T14:03:45Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hi,\n\nOn Wed, Jun 25, 2008 at 12:36:03AM -0000, David Jeske wrote:\n> The purpose of this mechanism is to host a distributed source repository in a\n> world where most most developer contributors are behind firewalls and do not\n> have access to, or do not want to configure a unix server, ftp, or ssh to\n> possibly contribute to a project. The model of allowing less-authoritative\n> developers to make their changes available for more-authoritative users to pull\n> is accepted as superior. However, no users are assumed to be authoritative over\n> each-other, or an entire tree, and many users should have authority only to\n> supply new deltas to their own branches. The ability to handle emailed patches\n> is an asset, but is deemed too manual for this need.\n\n  BTW, have you read about git-bundle(1)?\n\n> design assumptions:\n> \n> - all developers are firewalled and can not be \"pulled\" from directly.\n> - there can be one or more well-connected servers which all users can access.\n> - .. but which they cannot have ssh, ftp, or other dangerous access to\n> - .. and whose protocol should be layered on http(s)\n\n  Please note that we support pushing using the HTTP DAV extensions. It\nseems to be only rarely used in practice though, since developers seem\nto either work at sane companies, are tunneling through the firewalls or\nthe firewalls are adjusted if this is required for development of their\nday-job applications. There are some cases where this is useful, but I\ndon't tihnk they are very numerous (in practicular, I've had more\nrequests (about three?) for git-cvsserver than for HTTP DAV (zero to\none?) at repo.or.cz). Do _you_ have any real large-scale scenario where\nthis is an actual issue?\n\n> - there is a shared namespace for branches, and tags\n> - .. users are not-trusted to change the branches or tags of other users\n> - .. only certain users are trusted to change the shared origin branches\n> - .. also allow directory ACLS on shared branch commits\n> - all their DAGs should be in a single repository for space efficiency\n> - users generally want to follow well-named branches\n> - .. will be free to follow any branch, and pull changes from any branch\n\n  Of course, if pushing through the DAV extensions this can get hairy;\nif you allow push access for users, you better trust them since they can\ntouch the objects database. If you don't care about possible DoS attack\nvectors, I assume you could configure refs permissions for various users\nusing some fancy Apache configuration.\n\n  As previously noted though, I believe the space efficiency is not an\nissue in real world. Are you familiar with Git's alternates? In a Git\nrepository, you can specify alternate locations for searching objects,\nso you can create a \"sub-repository\" for each user, where an alternate\nis set up pointing to the object database of the main project\nrepository. Then, the bulk of the objects will be in the main repository\nand the sub-repositories will carry only tiny amount of objects specific\nto the local development of the given person.\n\n  This is exactly how (and large reason of why) the repo.or.cz forks are\nset up, by the way.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe last good thing written in C++ was the Pachelbel Canon. -- J. Olson\n"}]}