You can set a group as the owner of the server and all the members of that group will be considered owners. To do that you first need to create the group and then select the option to change the owner on the bottom side of the repository server permissions screen:
The repository server owner has nothing to do with the OS user used to start the server, it is just who has always permissions for everything in the server.
Could you reach us at support@codicesoftware.com and send the "plastic.debug.log.txt" file that you should have under "C:\Users\username\AppData\Local\plastic4\logs"?
As talked through e-mail, I'll paste here the answer in case it helps anyone else:
I'm afraid the reason why those cloaked files are being downloaded is that the incoming changes run a merge operation underneath, and merges need to be for the whole changeset
Regarding Plastic checking it out automatically, by default, PLastic can't do that. If you are using a plugin, it is probably the plugin the one checking it out. Another option would be if you are running a merge or an incoming changes operation. In those scenarios, Plastic does check the file put.
It is baffling to me why you can't easily tell which script has actually been changed. It seems like the display should be:
ScriptA Changed
ScriptB Checked-out
The thing with this is that a changed file and a checked-out file are different things.
A changed file is detected by the system and will only appear there if the changes were done locally.
A checked-out file notifies the server that it is meant to be changed. That's why the status cannot change from checked-out to changed.
ScriptA Changed / Checked-out
ScriptB Checked-out
For this other option, I can only agree with you. It could prove helpful and I'll share it with the team.
Regarding the "show checkouts" option, I go back to the first part of the answer. You are notifying the server that those files are going to be changed, and if you have lock rules configured, that's how you lock them. So it could prove useful to see which files you have locked and which ones you don't.
The cloaked.conf only works on controlled files, and it is to prevent changes from being downloaded into your machine. That means that new files (the ones appearing as added) will not be taken into account. If you don't want to submit the newly added items you need to ignore them.
To do a very quick sum up, we have three config files:
Ignore.conf: Prevents new files from being submited to the server and keep them local.
Cloaked.conf: Prevents changes in the server from being download into your machine.
Hiddenchanges.conf: Prevents changes in controlled files in your machine from being submitted to the server.
With that taken into account, the incoming changes should work as expected.
The problem comes because the libgnome2 library was deprecated in all modern Linux architectures. There is a workaround though, which is to add the repos from the old versions so it can be downloaded. Check out this knowledge base:
If you right-click on the file and then select "view history" you should be able to see all the changes made to that file.
You can also select the "View history as a 2d revision tree" to have a visual representation with branches and so on of the evolution of the file.
So you would like to have something like a mandatory build, or something similar?
I'm afraid that is not possible by default, but you could probably create a before checkin trigger that checks the content of the comment and rejects the checkin if it doesn't have those fields.
1
1
How to mark as done multiple CR request in one CS
in General
Posted
Best,
Héber.