[fossil-users] 2 questions
Hi, I have 2 questions regarding fossil: 1) if I have 2 projects do I have to a) create 2 separate repositories or do I b) put both source trees in one repository? if a), how do I run fossil server to make both repositories accessible at the same time from outside? 2) is it possible to deny access to folders of the source tree to certain users and grant access to the rest of the folders? (like in gitolite) thank you Zeev ps: I've asked Anjuta developers to create a fossil plug-in and they agreed :) https://bugzilla.gnome.org/show_bug.cgi?id=663313 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2 questions
On Fri, Nov 04, 2011 at 11:31:26AM +0200, Zeev Pekar wrote: 1) if I have 2 projects do I have to a) create 2 separate repositories or do I b) put both source trees in one repository? if a), how do I run fossil server to make both repositories accessible at the same time from outside? Create two separate repositories. If you put them in a directory and end the name in .fossil, you can point the server to the directory and serve both. 2) is it possible to deny access to folders of the source tree to certain users and grant access to the rest of the folders? (like in gitolite) There is no ACL on path names. ps: I've asked Anjuta developers to create a fossil plug-in and they agreed :) https://bugzilla.gnome.org/show_bug.cgi?id=663313 Nice! Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2 questions
On 04.11.2011 11:45, Stephan Beal wrote: @Everyone else: please correct that if it's wrong. No need of correction, I use fossil this way too: cat /etc/systemd/system/fossil.service [Unit] Description=Fossil Repositories After=network.target [Service] Type=simple User=fossil Group=src ExecStart=/usr/bin/fossil server --port 39127 /srv/source/fossil [Install] WantedBy=multi-user.target ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2 questions
On Fri, Nov 4, 2011 at 12:25 PM, Zeev Pekar z.pe...@gmail.com wrote: ** I do miss this feature... :( What is the best workaround for this today? To use a DVCS which supports this. i'm not personally aware of any. To developers: do you think this is important enough for you to implement it one day? It would be impossible to implement within fossil's world view. Once i clone a repo i have the whole thing, which i can then manipulate (with admin-level rights) on my machine - you cannot stop me from checking out a given path once i have access to a clone of the repo. There is no mechanism with which fossil can completely protect subdirectories unless it explicitly supports partial clones (pulling only part of the repo). If you mean to restrict _checkin_ access to a given subdir, i don't know if fossil _could_ do that, but it doesn't currently (and, IMO, shouldn't). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2 questions
- Original message - On Fri, Nov 4, 2011 at 12:25 PM, Zeev Pekar z.pe...@gmail.com wrote: ** I do miss this feature... :( What is the best workaround for this today? To use a DVCS which supports this. i'm not personally aware of any. gitolite supports ACL on paths if I'm not mistaken... To developers: do you think this is important enough for you to implement it one day? It would be impossible to implement within fossil's world view. Once i clone a repo i have the whole thing, which i can then manipulate (with admin-level rights) on my machine - you cannot stop me from checking out a given path once i have access to a clone of the repo. There is no mechanism with which fossil can completely protect subdirectories unless it explicitly supports partial clones (pulling only part of the repo). Ok, maybe implement partial clones? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2 questions
On Fri, 04 Nov 2011 13:52:04 +0200 Zeev Pekar z.pe...@gmail.com wrote: [...] It would be impossible to implement within fossil's world view. Once i clone a repo i have the whole thing, which i can then manipulate (with admin-level rights) on my machine - you cannot stop me from checking out a given path once i have access to a clone of the repo. There is no mechanism with which fossil can completely protect subdirectories unless it explicitly supports partial clones (pulling only part of the repo). Ok, maybe implement partial clones? I think the way to go would be to have something resembling Git's submodules. That is, keep each subproject in a separate repo and have a way to the commits in the master (intergating or whatever) repo to reference specific commits in those satellite repos (submodules). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2 questions
On Fri, Nov 4, 2011 at 5:31 AM, Zeev Pekar z.pe...@gmail.com wrote: 2) is it possible to deny access to folders of the source tree to certain users and grant access to the rest of the folders? (like in gitolite) With Fossil (or git or hg or mtn or bzr) each user has their own complete copy of the repository on their local machine. And so each user can do anything they want to their local copy of the repo and there is nothing you the administrator can do to prevent it. That's the nature of DVCS. Gitolite says it provides per-directory write permissions on the central repo. read permission is always per-repo. I presume they do this by denying push to repos that have modified directories that they are forbidden to modify. Or perhaps they are playing some really nasty games with rebase. But probably the former. Fossil does not do that and I have precious little motivation to make it do that. Fossil strives to be low-ceremony. By that I mean that you don't need a lot of central administrator setup and permission in order to participate in a Fossil-hosted project. The idea is that you trust your developers to do the right thing, to follow the rules you have created for your project, and to not modify files which they are not permitted to modify. This is not an unreasonable idea, since if you cannot trust your developers then you have way more serious problems. To complement its low-ceremony operating principle, Fossil also maintains a detailed and immutable audit trail and tools to detect and reverse undesirable changes and promote situational awareness. So if a developer does break the rules by checking into the wrong directory, he will be found out, the changes can be backed out, and the rogue developer can be dealt with administratively. I have used both low-ceremony and high-ceremony systems and I have found that the low-ceremony designs yield less frustration and greater productivity, which is why Fossil is designed to be low-ceremony and why I am so unmotivated to give it high-ceremony features. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
