Perforce "p4 edit" opens file in depot - edit

Im using p4v. When i checkout some file in workspace p4v shows next command in log:
p4 edit -c default d:\p4\depot...\file.txt
And I need to make same thing in cmd
All enviroment variables are set as:
P4CHARSET=utf8 (set -s)
P4CLIENT=workspace_name (set)
P4PASSWD=passwd (set)
P4PORT=port (set)
P4USER=name (set)
Then i use same command "p4 edit -c default d:\p4\depot...\file.txt" and p4 outputs this:
//depot/.../file.txt#5 - opened for edit
And if I check in p4v i see that file checked out in depot, not in my workspace.
What is solution to this issue?

Files in Perforce are mapped between your workspace and the depot, and the depot and workspace paths can be used interchangeably. When a file is "checked out" using "p4 edit", the following things happen:
Your local file (d:\p4\depot...\file.txt) is made writable.
The depot file (//depot/.../file.txt#5) is marked as being open by you.
The Perforce server "remembers" all of this.
That is, the file is indeed "checked out" in both your workspace and the depot -- there's no difference between the two. It's the same file. If you look at your workspace file, you should see that it is now writable (this is the signal in your workspace that it's checked out). From the command line you can run "p4 opened" to see which files are open in the current workspace. If you're not sure how the depot paths map to local paths for individual files, you can run "p4 have" to see where you have a given depot file in your workspace and what version of it you have.
When you submit, the server will know that the depot file needs to be updated, and it will know that the new content will come from your workspace file. If there is a new revision of the depot file (newer than #5), the server will schedule a resolve so that you can merge in the new content before submitting.
In other words, there is no such thing as being "checked out in the depot" but not in a workspace. A depot file that is "checked out" is by definition checked out to a particular workspace.

Related

AccuRev is ignoring my .acignore file

I have an .acignore file that looks like this:
**\build
**\build\**
**\.gradle
**\.gradle\**
My file structure is as follows:
AccuRev Workspaces
.accurev
Workspace1
Workspace 2
I placed my .acignore file into the .accurev folder under AccuRev Workspaces and restarted AccuRev. It didn't start ignoring any of the files that I expected it to (and they are all external). I then put it directly under the AccuRev Workspaces folder and restarted; still no luck. I even put it in both of those places under an individual workspace and it didn't work. I'm at my wits' end. What is going on here????
The .acignore file must be in the workspace top directory. In other words, you would need an .acignore in the Workspace1 directory and another in Workspace2. This allows you to have different ignore rules for each workspace. Alternatively, you could add it to source control if you have standard ignore rules applicable to all workspaces.

Force IntelliJ to use another Home Directory?

I have read this... it does not answer the question.
I would like to have IntelliJ use another location for all of my project files. Currently, it goes to c:\users\ as a default project location.
I want to change that to c:\git.
I tried to change the "Start in" link properties, to no avail.
I don't want to force all of the configuration (ie: the .IdeaIC15 folder) to be relocated, I just want it to go to c:\git when I click "Open project".
To change the directory where project files are located to C:\git:
Select Help->Edit Custom VM Options...
Add the following line to the end of the file that comes up in the editor (*):
-Duser.home=C:\git
Restart IntelliJ.
(*) The file that comes up in the editor will either be idea64.exe.vmoptions or idea.exe.vmoptions.
Notes:
This will update/create a .vmoptions file in your config directory. It does not modify the vmoptions file in your install directory.
The above steps do not change the default directory that is used
when cloning git repositories. This is the directory that is used in
the File->New->Project from Version Control->Git window. You
still need to set that directory to C:\git and clone one remote repo
into C:\git. Once you have done that IntelliJ remembers the directory and
uses it for subsequent clones.
https://intellij-support.jetbrains.com/hc/en-us/articles/207240985-Changing-IDE-default-directories-used-for-config-plugins-and-caches-storage
Locations can be changed by editing the following file:
IDE_HOME\bin\idea.properties
Follow the comments in idea.properties file to change the defaults, make sure to un-comment the lines defining these properties:
idea.config.path
idea.system.path
idea.plugins.path
idea.log.path

Accurev - why file status is incorrect?

I have modified few files locally by windows copy command but when I saw the status of modified files in AccuRev it is still shown as backed. Eventhough the file is modified then why it show the status as backed.
Any clue?
Thanks,
Sanjiv
You copied a file into your workspace that has an older timestamp than the workspace scan threshold time.
If you turn off "Timestamp Optimization" and click refresh, the file will appear as modified.
Or if you run the command "accurev touch " and then hit refresh, the file will appear as modified.

Backing up source files managed by source control software: TortoiseSVN

I am new to source control and I am confused with something I read on a webpage yesterday (I don't have the link). I have followed these instructions: "create folder structure", then "Start Reprobrowser", then copy source files into trunk folder. Please see the screen shot below:
However, when I navigate to the folder using Windows Explorer I do not see this folder structure. I see this:
Therefore I am wandering: where are the files physically stored? The reason I ask is because I want to ensure that NetBackup (corporate backup tool) backs up the correct directories.
To make sense of the repository structure you need to read all the documentation on SVN, but the preferred way to backup a SVN repository is through the command
svnadmin dump your_svn_repository_path > destination_filename_backup.svn
You could put this command in a scheduled task running sometime before your corporate tool execute the full backup of your data and include the destination_filename_backup.svn in your backup job
If you ever need to restore the backup (after recreating the repository) you could use the command
svnadmin load your_svn_repository_path < destination_filename_backup.svn

What does Main.1 output file do in XCode?

I made a sample project called "Stack", but realized that i needed some more data structures, so i renamed everything - the project, made 2 new folders & their matching groups in XCode, modified the Target Build path to look for "Main/DataStructures-Prefix.pch" instead. But there's one file i don't understand -> earlier, i had gotten a "Stack.1" in my folder, so i just renamed it to "Main.1" and it doesn't seem to be affecting the build process, but i'm pretty skeptical. What does this "Main.1" do? is it the linked intermediate file like in C/C++?
here's a picture:
"Main.1" is a template for creating a "man page" (i.e. an on-line manual page) for your program. You can verify that by calling
man ./Main.1
on the command line in the directory where "Main.1" is located.
If you run
xcodebuild install
on the command line then the manual page is copied to the
$DSTROOT/usr/share/man/man1/
directory, where DSTROOT is the "Installation Build Products Location". The file is not used otherwise in the build process.
If you don't need a man page, you can just remove the file from the Xcode project.