I'm trying to call a p4 sync command on a local path from within python.
P4dir = "D:/Perforce/Project/*"
subprocess.call("p4 sync " + P4dir)
This fails with a non-existing directory error.
However, if i call the sever path, it works fine:
P4dir = "//depot/Project/*"
subprocess.call("p4 sync " + P4dir)
This is probably extremely simple and I'm a bit embarassed i have to ask, but the documentation for P4 commandline arguments is lacking a lot.
So is there perhaps a way to translate a local path, should be simple by just checking the mappings?
You can use p4 where to convert local paths. Example:
$ p4 where /home/user/perforce/project
//depot/project //the_workspace/project /home/user/perforce/project
I tired this on a Linux box so the local path is *nix style, but it should work on Windows as well. p4 where also works with relative paths like ./some_folder which is very handy.
I'm suspecting P4 does not realise that you intended to pass it a local path. (In Unix sense, it does not look like one.) Have you tried executing p4 sync * with D:/Perforce/Project its current directory?
On a different tack, if your P4 binaries have been built with Cygwin, you may be able to specify the path as /cygdrive/d/Perforce/Project.
Related
I'm trying to understand how perorce work and I'm struggling with command line
I have a single depot with 3 project inside
so depot:
projectA
projectB
now I have 2 workspaces, one mapped only on projectA and one on projectB.
Here I have my trouble , using interface everything works
but with command line I have not enough knoledge on perforce.
I use
p4 -c workspacA //to switch workspace
then I run: p4 cstat
and it give me all the information about changelist contained in all depot
not only depot/projectA
But I woul like to enter in a workspace and run my command only on that workspace
Is this normal? I see that I need to specify my depot mapping but this seems strange to me.
Can someone clarify me this?
Thanks
Do:
p4 set P4CLIENT=workspaceA
If you use -c workspaceA it applies only to that one command, whereas p4 set is persistent.
I also recommend looking at documentation on P4CONFIG, which lets you associate Perforce config settings with local directories (so you switch workspaces automatically when you cd to a different workspace root).
https://www.perforce.com/manuals/v16.2/cmdref/P4CONFIG.html
I am trying to write a maven compile command and want it to work on my colleagues' machines as well, and since they have a different perforce depot path than mine, I need a unified way to find it.
I have tried p4 where but it didn't help.
When you run the p4 where command make sure that you're using the correct client workspace.
E.g.:
p4 set P4CLIENT=my_client_name
p4 where //depot/...
or:
p4 -c my_client_name where //depot/...
The example you describe of p4 where returning the wrong path indicates that it's giving the answer in terms of a different client workspace.
I have a Tcl script that works on Windows. When I run it and pass in file names when prompted, usually with a relative directory path. On Windows the script will take absolute OR relative directory paths ... it works, no problems at all.
On Linux it will NOT work in the same way. It will only work if I spell out the full file path, e.g. /home/gxuser/input/test.txt ... It will NOT take relative directory paths like ./input/test.txt
By "work" I mean it should OPEN the file ... It is there and the permissions are fine.
On Linux the program fails with the following error:
couldn't open "./input/test.txt": no such file or directory
while executing
"open $upload r"
The offending line in the code is:
set infile [open $upload r]
What am I doing wrong? I presume, I have overlooked some nuance of the Tcl language, and assumed it should recognize relative paths.
Relevant information:
% puts $tcl_version
8.4
% info patchlevel
8.4.19
% uname -a
Linux gxengine 2.6.32-60-generic #122-Ubuntu SMP
It is possible that a function you call is changing the current working directory. There is no way to tell which one that could be without inspecting the code, but you can check if this is the case by displaying [pwd] before calling open.
Another way things could go wrong is by the script being started in different ways from Unix and Windows - e.g. by shortcut on Windows and from the command line off the PATH on Unix.
Where you have filenames passed in by the user and you can't be sure that code you call won't cd under your feet, you're advised to process the filenames into absolute filenames as soon as possible in your script, possibly even before any package require or source calls.
This is actually easy to do.
set absoluteFilename [file normalize $userProvidedFilename]
As long as this is done before the first cd (or chdir()/SetCurrentDirectory() at the C/C++ level) future changes of directory will not break the path. The script must be prepared to work with absolute filenames, but that's easily done.
You can turn a relative path into an absolute path with respect to any arbitrary directory with file join:
set filename [file join [file normalize $arbitraryLocation] $relativeFilename]
(The file join is smarter than just inserting a directory separator.)
I need to find out if file/folder is under specific source control.
The easiest way of doing this is to find some hidden folders. (this does not guaranty that partifical file is under source control, but with some probality says that this source control was used )
It's quite straightforward with SVN, GIT, as they have hidden folders.
But I can not find the same things for Perforce and ClearCase. Are there any universal way to understand what VSC is used in those paricular cases?
Perforce does not litter the drive, but keeps the info on the server. Also, files can be mapped in different structures, and mixed with non-controlled files, so it's not something you can determine by looking at the file itself.
However you can simply ask Perforce. For example, at the CLI:
P4 fstat FILENAME
Will give you info about a file if it is under source control.
If you need to script it for Perforce, there is an option (-s) that makes things easier (since the exit code of p4 doesn't indicate success or failure of the Perforce command). So, for bourne-like shells something like this should work:
if p4 -s fstat FILENAME | grep 'exit: 0' >/dev/null 2>&1 ; then
echo "Perforce knows this file"
else
echo "Perforce don't care"
fi
For ClearCase, you will find a hidden file named view.dat at the root directory of a (snapshot) view .
If the file is under M:\ (Windows) or /view/vobs (Unix), no need to look for an hidden file or directory: you know it is a dynamic view.
Another way is to execute, in the parent directory of a file:
cleartool lsview -cview.
If that directory is in a view, that command will return its name.
Similarly, i you can run a command like p4 reconcile or p4 status, and it doesn't return an error, chances are you are in a Perforce workspace.
How do I get a GUI-based merge tool to work with command line SVN in linux? I understand that there are many options like meld, svn Diff, etc. out there. All of them require a helper script to allow svn to invoke the external program during conflict resolution. I followed the instructions given here and the nice svn manual with meld.
But in all cases, when I get to the merge conflict and type 'l' to invoke the external tool, I get an error: The external merge tool exited with exit code 255
I'm fairly certain I'm missing some key thing here. ITs too much of a coincidence for so many different solutions to fail. Would appreciate any solution or pointers to the problem.
Thanks!
Also make sure that the path in your config is absolute. It should be the same path you see when you run a pwd command from that directory. No aliases or relative paths. So if your username is foo you would replace this line:
Add this below it:
merge-tool-cmd = ~/bin/svn-merge-meld
With
Add this below it:
merge-tool-cmd = /Users/foo/bin/svn-merge-meld
You may not have the correct permissions on the wrapper script. Try something like this:
sudo chmod +x /usr/local/bin/mergewrap.py
I've found several wrapper scripts for vimdiff or meld which seem to pass the wrong number of arguments. Unless I've misunderstood the rather terse documentation about the commandline parameters, they only take 2 or 3 filenames. This may also cause the script to fail with an error.