Does Vault provide any mechanism for controlling who can create and/or merge branches, or apply labels?
Our dev team isn't huge, but its big enough that we don't want everyone to be able to do those things as they see fit - we'd much rather have control of those actions in the hands of a smaller group of administrators to preserve a clean, usable development tree.
Security question
Moderator: SourceGear
Sorry to awaken an old thread - better than starting a new one though.
We've now rolled out Vault to approx 20 developers, some accessing it remotely from half a continent away, and most are extremely happy. A couple of users have performance issues, and for one person its severe - enough to make Vault unusable on his machine (its a quick enough machine, we haven't found any reason for this yet). Vault can be very slow with folders that have lots of files - it can take minutes to open them, then if you put Vault to the background & then bring it to the front it takes minutes again to repaint the display.
But I digress! What I meant to talk about was:-
We have a repository that we really don't want to set Folder Security on. Ideally therefore we'd setup a few Groups with appropriate rights to the repository & assign people to the groups as required. What's confusing me though is that Group Security consists of "No Access, Access, Full Admin", whereas with Folder Security you can setup RCA abilities, ie Command Rights. What does "Access, Full Admin" mean? I can't find a clear definition of them in the help text.
Wouldn't it be more consistent to dispense with "No Access, Access & Full Admin" and instead assign Command Rights in Group Security? That way we could be confident that groups have exactly the rights we want them to have.
(In the context of the questions in my earlier posts, perhaps a B could be added to Command Rights for branch management and a D for delete? Maybe an O for obliterate?)
Hope that all makes sense
We've now rolled out Vault to approx 20 developers, some accessing it remotely from half a continent away, and most are extremely happy. A couple of users have performance issues, and for one person its severe - enough to make Vault unusable on his machine (its a quick enough machine, we haven't found any reason for this yet). Vault can be very slow with folders that have lots of files - it can take minutes to open them, then if you put Vault to the background & then bring it to the front it takes minutes again to repaint the display.
But I digress! What I meant to talk about was:-
We have a repository that we really don't want to set Folder Security on. Ideally therefore we'd setup a few Groups with appropriate rights to the repository & assign people to the groups as required. What's confusing me though is that Group Security consists of "No Access, Access, Full Admin", whereas with Folder Security you can setup RCA abilities, ie Command Rights. What does "Access, Full Admin" mean? I can't find a clear definition of them in the help text.
Wouldn't it be more consistent to dispense with "No Access, Access & Full Admin" and instead assign Command Rights in Group Security? That way we could be confident that groups have exactly the rights we want them to have.
(In the context of the questions in my earlier posts, perhaps a B could be added to Command Rights for branch management and a D for delete? Maybe an O for obliterate?)
Hope that all makes sense
There are two types of security, Repository Access (Access, No Access, Full Admin), and Folder Security (RCA). Folder Security controls what users can do, and Repository Access controls whether they can see the repository at all.
As for the other issue (which I'd really like to solve), what version are you on? Would you be willing to have that user turn on Vault client logging and reproduce the problem?
As for the other issue (which I'd really like to solve), what version are you on? Would you be willing to have that user turn on Vault client logging and reproduce the problem?
Subscribe to the Fortress/Vault blog
Ah ok thanks, that makes sense (re the security). We're running 4.1.1 atm, soon to transition to 4.1.2.
Log file is attached - It starts on firing up Vault, which opens in the worst-performing directory. Once that was done, I brought another application to the front and then switched back to Vault. I've added a blank line into the logfile to separate the two events.
From my ill-informed reading of the file it seems that BackgroundChangeScanEvent is the culprit. Btw, why does it need to do this every time a folder gets a "repaint" event?
Anyway, I hope that helps!
Edit: more ill-informed speculation. If Vault really does need to go off & update things, would it be possible to have it done in the background? Assuming its capable of showing the list of files, if the user could still do things in the interim then I'd consider the problem fixed. Its all about perception - if the users aren't wasting time looking at a sand timer then they're generally happy
Also I should point out that that directory has some 5,300 files in it, and unfortunately breaking it down into smaller sub-directories is not an option :\ We have another with 3000 files in it as well.
Log file is attached - It starts on firing up Vault, which opens in the worst-performing directory. Once that was done, I brought another application to the front and then switched back to Vault. I've added a blank line into the logfile to separate the two events.
From my ill-informed reading of the file it seems that BackgroundChangeScanEvent is the culprit. Btw, why does it need to do this every time a folder gets a "repaint" event?
Anyway, I hope that helps!
Edit: more ill-informed speculation. If Vault really does need to go off & update things, would it be possible to have it done in the background? Assuming its capable of showing the list of files, if the user could still do things in the interim then I'd consider the problem fixed. Its all about perception - if the users aren't wasting time looking at a sand timer then they're generally happy
Also I should point out that that directory has some 5,300 files in it, and unfortunately breaking it down into smaller sub-directories is not an option :\ We have another with 3000 files in it as well.
- Attachments
-
- vault.txt
- (18.18 KiB) Downloaded 228 times
4.1.2 specifically had some fixes to fire the BackgroundChangeScanEvent less (for another user with 5000 files). You can upgrade your client to 4.1.2 without upgrading your server, if you want to try the fix ASAP.
Subscribe to the Fortress/Vault blog
I'll add that 4.1.2 included a host of performance fixes in the Enhanced IDE client. You posted about some performance issues a while back, and 4.1.2 should make things substantially better.
Ian Olsen
SourceGear
SourceGear