<br><br>
<div class="gmail_quote">On Thu, Sep 30, 2010 at 4:11 AM, Alexander Belchenko <span dir="ltr">&lt;<a href="mailto:bialix@ukr.net">bialix@ukr.net</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im"><br> </div>That&#39;s would be cool. But back to bzr-access. Am I understand correctly something different will be used instead of the bzr-access?<br><br></blockquote>
<div> </div>
<div>Yes, I think that&#39;s correct: bzr-access was not designed to meet all of the requirements currently being discussed, although bzr-access does support *some* of the requirements.  Those requirements may include:</div>

<div> </div>
<div>1. a distinction between read-only and commit permissions</div>
<div>2. per-branch permissions.  (I do not have a need for anything finer-grained than branches, but I can see a use-case for relative-path permissions also)</div>
<div>3. support for groups of branches (to which permissions could be assigned all at once)</div>
<div>4. support for groups of users (e.g. Team Alpha = [jose, nico, martitza],  Team Beta = [jose, alicia, jorge] )</div>
<div>5. support for &quot;remote, remote&quot; branches -- ACL server manages &quot;pass-through&quot; access to branches on arbitrary boxes on the network, not just on itself</div>
<div>6. scriptable... even if an excellent GUI is also available</div>
<div> </div>
<div>Suggested requirement #5 is not strictly necessary but may be helpful in highly distributed organizations, so that one interface can manage all of the machines serving branches.  The end-user would not need to go through the intermediate machine necessarily.  Instead, the admin console would have the ability to set up the permissions on each of the other smartserver boxes.</div>

<div> </div>
<div>~M</div>
<div> </div>
<div> </div></div>