On 7/22/2013 4:36 AM, Stephan Beal wrote:
On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras <emorr...@yahoo.es <mailto:emorr...@yahoo.es>> wrote:

    Similar, a C developer role can modify /src dir but not
    /documentation or /sql, the DBA role can change /sql but not /src
    and similar. Role info is already exchanged in pull/push/sync,
    user info not. So in your scenary, a user can get the role
    capabilities and access them.


So what happens when i (as a wiki editor) make a change to src/foo.c, commit it to my local copy (because locally i have admin access) and then try to push? i can't, and my repo then gets (permanently) out of sync. i don't think this model is possible in a DVCS.

    The problem is that a user is admin of his own repository file and
    can set whatever s/he wants and access everything. A global dvcs
    role and user data can solve this, not allowing this user make
    changes in public branches or trunk directories of central repo
    (or other users repos) if s/he has no privileges to do so.


Once i clone it, the central repository has NO say-so in what i can and cannot check out. It can only control what i check IN, or (more correctly), what i try to push to the central server. If it will not let me push the changes i have already committed to my local repo then i have a serious problem.


Actually, I think something similar already exists, as shunning. If you commit an artifact to your local repo that has been shunned at the central repo you won't be able to push it to the central repo. I didn't actually try that, though, so I don't know what the user interface behavior is -- perhaps it appears to sync and silently drops the shunned artifact.

If the user interface for committing a shunned artifact is or could be made friendly enough, then perhaps the requested behavior of user-level commit restrictions could be achieved by generalizing the shunning code path. Instead of just "deny if artifact is in shunned list", allow "deny if username is foo and filename is bar".

(I haven't actually looked at the shunning code, though, so it is entirely possible that the above would not be feasible.)

--
Edward Berner

_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to