Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote:
> Jan Rychtar wrote:
> >
> > Yes, it works good, but... wouldn't it be more straightforward if the "no
> > branch specified = match any branch" rule worked for all users and not
> > just "default"?
> That would be a major change in behaviour, and would break existing
> setups. It also doesn't make a lot of sense to me - If I give read
> access to a user I don't expect that permission to propogate to branches
> automatically. Default means 'default for all branches' now, which is
> at least intuitive, but starting to make the user permissions bleed into
> other branches is not intuitive at all.
Well, I see. It's about the point of view. If you use cvs the
"traditional" way, you have one main trunk everybody is working on, and a
couple of branches for release bugfixes, which you want to protect.
But I plan to use cvs the opposite way. I'll have one protected supervised
main trunk only the dev boss is allowed to write to, and theoretically
unlimited number of side branches for developers. Developer implements his
new super feature into his own branch, comes to the boss, who merges the
feature into main trunk. Other developers then can merge that feature into
their own working branches.
Now I can think of a situation, when I would like to set permission for
specific developer to all branches. (other than default) For example I
would like to have senior developers, who can write to other developer's
branches, and junior developers, who can write just into their own
branches.
The point is that I am unable to do it now, because there is no way to say
"this developer, any branch". I must explicitly list all active branches.
And the solution seems to be just step away, because now we have two
statements with the same meaning ("user" and "{HEAD}user"). So why just
don't use the first one for "any branch"?
But I understand that my development model is quite unusual, maybe even
wrong, and my point of view must seem inside-out to you. And if not, it's
definitely not worth it to change the accustomed behaviour.
Best regards
Jan Rychtar