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