We Currently use Perforce here and Finalbuilder. I want to be able to tie through finalbuilder into my perforce location so I can control the source.
We use different methods to obtain items from Perforce. Command Line(P4) P4Win and P4V. This works well and many accounts can get the latest check otu and work on the projects. I want to be able to do this via FInalbuilder but what I am seeing since we are password protected that Finalbuilder is setting variables within the project causing this project to prompt for password for other users to the user that submitted this projects.
Is there a way NOT to have it prompt and use the machine Perforce information to source control this project?
The issue seems to be steming to
Both are embedded inside the uncompressed Finalbuilder project!
I don’t know all the intricacies of Perforce and P4, but each of the Perforce actions allow you to specify the user/password/hostname/working dir etc, or to use the Perforce defaults for that user. So, I suspect what is happening is that by specifying these various options, Perforce (via P4 as that’s what FinalBuilder uses) is resetting the defaults for that user? I’m not sure how you could work around this… maybe it’s something you can ask on the Perforce forums?
It looks like it is adding the current user to the finalbuilder projects. We are using Password Protected connections and found from the log that it embeds the current user into the project. Otherwise it prompts for the last user that checked in the project. We think that if the user and dataclient name is not used that we will not be prompted.
Our work around is modify the project outside of finalbuilder and submit it within Perforce with either the GUI or command line which works. and have the project pulled down the same way through the dataclients that they can access this file. Not thought the Finalbuilder. If we try and get it to be source controlled via finalbuilder then it takes the ownership of ther person the binds it to the perforce location. We are not using the overrides on that finalbuilder and using the defaults.
I’m not sure what you mean by “embeds the current user into the project”? Which project? and are you saying the FinalBuilder embeds the current user in the project?
The Project I am trying to use with Source control embeds the user account and perforce client within the project. When someone else uses perforce and syncs down via there client to their machine and executes the finalbuild prject. I prompts for the password to the use that submitted the project. I think this is because it has that user information included into the project. there should be a way to use the default account that was used to sync the file down instead of within the finalbuilder project.
I’m not sure how FinalBuilder can do that, apart from not supplying the username/password on the command line (which is what the “Use Perforce Defaults” setting does)?
I think we’ve been discussing different things here, I thought you were talking about the Perforce actions, but I think you’re actually talking about the FinalBuilder SCC integration, right? In this case, afaik the SCC Perforce integration in requires you enter a username/password and I’m not sure if there’s any way around this.
FinalBuilder SCC integration, I think this is it. Where it comes into play is when two people try and use the same Source Controlled project.
Perforce,set up with username and password. Have each user setup dataclients to the file location within perforce. Have user A check it into perforce. A finalbuilder project uncompressed! Have user B pull down the proejct via perforce to have it on his local machine. Have user B try and execute it. Since it is perforce controlled! We get prompted for the password for user A. If you unbind and resubmit with User B. then he takes ownership and his Username, Password and Dataclient is now part of the Perforce project!
If you unbind and go to submit in peforce and compare the two projects you will see that the finalbuilder project has embedded the username/password as well as the dataclient.
Other items we use do not embed the Perforce information within them and I can use the perforce to control what is happening with the project to various users.
Not sure if we can do this with finalbuilder, but it would be great to have a way to not use the FinalBuilder SCC integration account information within the project.
Controlling the project outside of Finalbuilder and manually submitting it within perforce is a work around, but this can lead to issues if various personnel would like to work with the project at hand.
Unfortunately, this is a limitation of the SCC integration. The plugins for different source control tools actually choose what data to embed in the field in the project, and whether or not to allow other users, etc. You could write to Perforce and ask for the ability to override the user when a project is bound to source control.
Another alternative might be to create a user just for the build projects. Obviously this reduces the effectiveness of source control (because you don’t know who makes changes), but it works around this limitation.
We could change the behaviour so the SCC auxillary data was embedded in the .fbpinf file instead of the project. However, Perforce is the only provider I know of that does not work with the current behaviour.
Thanks, I will pass this onto our Perforce Contact here. With the option of the user for the build projects, we do have this here, but if you want to track to a real individual, you lose this. We can perform this but then we have to go back to adding the modified signature to the project to find who updated the project last as well as others could not enhance upon the project if required when they do not know that user information and password!
I’m Dennis’ coworker and one of the administrators for Perforce at our company. I think we can help Dennis out. He showed me today how the Perforce credentials for their SCC are kept in the project itself. I’m interested in what you wrote in the last line of your comment.
We could change the behaviour so the SCC auxillary data was embedded in the .fbpinf file instead of the project. However, Perforce is the only provider I know of that does not work with the current behaviour.
If each user had their own .fbinf file it would be easy for them to enter in their Perforce credentials. What do you mean though by Perforce “does not work with the current behavior”?
With the MS SCCI API (which is what the SCC integration uses to bind projects to source control), each provider (ie the plugin provided by each source control vendor) gets to store a string in the project file to describe the details of the binding. FinalBuilder doesn't know what lives in that string, we just read and write it from the provider (in this case Perforce) , and we're none the wiser.
In the case of other providers we've worked with, the provider may store some credentials in the file but it's also smart enough to realise that if the project is loaded by another user, on another machine, from a working directory that belongs to that user, then it should use the other user's credentials.
Apparently, the Perforce provider doesn't do this and insists on using the credentials that it stores with the project.
I'll see what we can do about adding an option to store the details in the .fbpinf file instead of the project. This would mean that each user can have a local copy of the binding details, as long as they don't want to check the .fbpinf file into source control along with the project.
Has this been implemented: Adding an option to store the details in the .fbpinf file instead of the project. This would mean that each user can have a local copy of the binding details, as long as they don’t want to check the .fbpinf file into source control along with the project.