On 14 December 2013 03:01, Andy Bradford <amb-sendok-1389600082.mcoojgfhogdpelaif...@bradfords.org> wrote: > Thus said Ron Wilson on Fri, 13 Dec 2013 21:57:22 -0500: > >> Since you are providing a server with Fossil repos on it, your build >> could work the way you want it for your students to use SSH for access >> using "stock" builds of Fossil. > > This is a really good point. > > David, it is already possible to set this up in the way you intend and > the students will be able to use the current release of Fossil 1.27 to > accomplish it.
That's great! I had obviously misunderstood. I thought that the client side had different interactions because it used to interact with the shell, and now didn't. But if the current distribution on the client side works with the new version on the server side, that'd be great. > For example, if the name of the shared SSH account is fossil, there are > two possible ways to have them clone: > > First: > > fossil clone -A user1 ssh://fossil@server//user1proj.fossil proj.fossil > fossil --user user1 user -R proj.fossil default user1 > > Second: > > fossil clone ssh://fossil@server//user1proj.fossil proj.fossil > fossil user -R proj.fossil new user1 > fossil user -R proj.fossil default user1 > fossil user -R proj.fossil cap user v > > I think the first might be the preferred method at the moment. > > The reason why it is necessary to set the admin user and the > default-user is because Fossil now extracts the user out of the URL and > uses that as the admin user, which means if you are using a shared SSH > account named ``fossil,'' all commits would appear to come from > ``fossil'' which isn't likely what you want to show up in the timeline. > The rcvfrom table would actually record the actual fossil user that > performed the sync, but the artifacts would all show ``fossil.'' OK, I understand this to a fair degree, but I could use some clarification around users on the server and client. 1) I need to create maybe 60 fossil repos. They will be identical with me as admin, the TA, and the student as developers. Obviously I want to script this. fossil init does most of what I want, and if I set up a template with minimal (or no) capabilities for "anonymous" and "nobody" (I don't think "reader" matters) I should then get the right thing, then just add the 3 users above. 2) I don't plan to run the ui for the student repos, but I don't think that limits us. The students could obviously run it on their copies, if they wanted. 3) I don't understand the admin-user fully particularly server vs. client. If I am the admin on the server, is there a reason why the students need the -A on the clone command? Do they need to be admin, if all they are doing is committing code? I would have thought all they needed was: fossil user -R proj.fossil default user1 to make their commits tagged properly. Even that shouldn't really be necessary as long as the TA and I tag our commits properly, everything else will be the particular student whether it shows as them or 'fossil', no? Of course if it were a group committing to one file I'd want the id's right. 4) could I not add code on the server side to use the user from the ssh forced command to tag the commits, or are they just copied over unchanged from the client and changing it would somehow break something? Where is the recvfrom data available? only on the server? only in the GUI? On the server could I refuse commits if the tag on the commit differed from the ssh force tag? > Hope this helps. If you have any more questions, let me know. Yeah, it helps a lot, thanks. Sorry for all the questions. ../Dave _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
