I have just been allocated a RHEL 6.8 box, I'd like to set up a perforce workspace there. How can I set that up? I don't believe it has p4v installed there(maybe that's step 1). Any help or assistance would be much appreciated.
Yes, installing p4 or p4v would be the logical first step.
You can find the downloads at https://www.perforce.com/downloads/helix.
I recommend starting out with plain old p4, the command-line version,
because it is easy to follow the steps for a command-line interface
when getting started.
Documentation for setting up a workspace is at https://www.perforce.com/perforce/r15.1/manuals/p4guide/chapter.configuration.html#DB5-17566.
Setting up a workspace presumes that someone has already set up a Perforce server that you can use through your workspace. You will want to get the server information from another user or the administrator. Earlier sections of the same documentation web page detail what to do with the server information once you have it.
Hope this helps.
Related
While working with some projects checked out from Git, we get errors with modifying the project settings in MyEclipse. I am trying to modify the deployment values in my workspace and it is not letting me (screenshot below).
There isn't a lot of information to go on, here (e.g. what is the version of MyEclipse, what type of project is this, what properties page are you switching from, the OS and version, whether this has worked before, the error log - but please don't paste that in here - and so on).
However, here are some actions that might help resolve it:
Firstly, try a fresh empty workspace then import the project from the old workspace, or better still import again from Git. This would help clean up possibly corrupted settings in the workspace.
Another thing to try is to launch MyEclipse with the -clean option (just add that option to the top of your myeclipse.ini file, found in the installation folder).
#Howlger is right, though, this is a commercial product and we may be better able to help if you raised the issue in the MyEclipse support forums.
I use Team Foundation Server for Source Control and in my Visual Studio I unckeckd the Option: "Multiple Check Out".
But when I check out a file and modify it another user can still check out the same file and also modify it.
What went wrong??
If you have to look at this issue then you are probably not checking in enough. Its a workflow and not tool change that is required.
TFS only supports the single checkout model if all users are using Server Workspaces. The default changed in 2012 to Local Workspaces which does not support this.
https://msdn.microsoft.com/en-us/library/ms181383.aspx
Check out the MSDN documentation for how to change workspace modes.
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
I hope this is not an incredibly stupid question.
According to what I can find online, it seems forking was added to GitLab in version 5.2. However, I can't seem to find in trace of it in the web UI. Or the help files. Or much anywhere else.
Is this perhaps a premium feature or something?
Or should it be activated/enabled somehow?
Thanks.
Also a side-note, if you haven't committed any files yet, fork option will not show to other users. you need to at least add a readme file in order fork a project.
The scenario : you have a main project at startup phase and multiple developers will be working on it. You created main project in root repo, logged out , logged with your user to for project for initial set up, fork option is not there.
Ok, I was being an idiot (sort of).
Seems if you login with a DIFFERENT user (i.e. a user who is NOT the owner of the project), the fork functionality shows up clear and plain.
Excellent then.
Props to the GitLab team - loving it!
I have recently upgraded to the new Azure SDK (September 2011 v 1.5).
Ever since I have not been able to start the compute emulator. Consequently I can't debug the services on my local machine.
I have seen a suggestion that the problem lies with the fact that my user account has a space in it, so I renamed my account but that didn't make any difference. It may be that the problem is that my user profile path has a space in it. Changing the account name has no effect no the profile path.
On the msdn forums it was suggested that I remove *:808 binding in IIS Manager for Default Website. See MSDN Forums
Anyone have any other ideas?
Another option:
So, given the "rename your user account/regedit doesn't work for you, you may want to look at this MSDN article, which suggests you can just set an environment variable and run the emulator without mucking with the registry... not sure if setting the environment variable globally would let you run automatically within VS.NET without manually starting up the emulator the first time, but it is certainly easier.
Yes, the space(s) in your profile path are the issue, and this appears to be a regression for a bug that was found in a previous version of the emulator (the only reason I even thought to try logging in with a different account in the first place). I was literally just putting together a quick blog post here describing the same issue. You'll need to do some registry editing to fix all the references to your old profile path if you want to fix it, or just create a new user if you can deal with re-installing software (I love the Web Platform Installer, but I found out during this exercise that it doesn't do a good job installing for "all users").