This is a very basic query, but I am using perforce to create a workspace for a particular project that is deep in the depot directory.
Hence, on windows I am facing a warning as to "File name ... exceeds the limit of 260 characters"
I am trying to search a way to limit the folder structure to something just like : "C:\p4\dept.. " without the long list of folders.
Is there an easy way to do this?
I have come across following similar solution on :
[http://answers.perforce.com/articles/KB/3051?startURL=%2Farticles%2FKB_Article%2FSubmitting-or-Syncing-Files-with-Long-Path-Names][1]
But, cannot find out the command execution.
Is there a better, easier way to do this ?
The local paths (which exceed 260 chars in your case) are composed by concatenating
the workspace root
the paths (relative to the workspace root) as defined by your mapping.
To shorten the two, open Connection > Edit Current Workspace in P4V. Then
Shorten your Workspace root (e.g. to C:\p4)
Shorten your mappings:
In the same dialog as above, expand Workspace Mappings. This may be displayed as a graphical tree view. If that's the case, click one of the icons near its top-right corner to switch to a text-area view.
In the text-area view, each line has two parts: the depot path and the local path. The local path is something like //foo/some/relative/path/to/bar, where foo is your Workspace name. Shorten it to something like //foo/bar.
This should produce much shorter local paths.
Related
Whenever I add a new file to the project, it is added with the default location of "Relative to Group" and a problematic path of (for example):
../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift
It's not as if I put the file in another user's directory. In this case, ../myUsername resolves to .. Same with every other double dot. You could simplify it as follows:
../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift
../../../../Folder/Foo/Foo/Foo/Bar.swift
../../../Foo/Foo/Foo/Bar.swift
../../Foo/Foo/Bar.swift
../Foo/Bar.swift
Bar.swift
Because it literally is going down the path then going back up the same way. It is equivalent to running cd ../; cd ~- in a shell.
I expected the path to be simply Bar.swift. This causes many problems when using shared code because other people have the project in different places with different usernames.
The only solution I have found so far is manually editing the project.pbxproj file. What is causing this problem and what should I do to fix it?
Note: I suspect that this might have to do something with the case of the username due to the fact that the username is as far back as the path goes.
EDIT: Here is a screenshot (red is my username, and green is the app name):
Also, cding to the directory and running realpath ../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift returns Bar.swift.
EDIT 2: My suspicions were right about the username being case-sensitive! Look what happens when I set the Location to Absolute Path:
Previously, the username was only Title case (../MyUsername, /Users/MyUsername, etc.). However, now Xcode seems to go:
Down the directory tree from the lowercase username (to the group folder)...
Past the directory containing the project...
Into the directory containing the file...
Back up to the Users directory...
Down the same path with the Title case username.
I think that this is a bug in Xcode. If I had to guess, what happens internally is:
Xcode gets the absolute path to the file
From a file picker while adding
From a file picker while relocating by pressing the folder icon in the Location section
Somehow from creating a new file(?)
This path uses the Title case username.
Xcode gets the absolute group path
From its records (project.pbxproj?)
For some reason, this path uses the lowercase username
Xcode tries to figure out the path from #1 relative to the path from #2.
For example, if the path to the file was /foo/bar/baz.swift, and the group was /foo, the intended result is bar/baz.swift.
Xcode starts at the absolute path to the group (because the end path should be relative to the group).
Xcode looks at both paths and compares them. /Users/myusername/Folder/Foo/Foo/Foo vs /Users/MyUsername/Folder/Foo/Foo/Foo/Bar.swift.
Xcode sees that the only differences are:
At the end of the path (one has the filename and the other does not)
In the username (myusername vs MyUsername)
Xcode moves up to the farthest problem up the file tree using the double dot (../). /Users/myusername/Folder/Foo/Foo/Foo/../../../../.., or simply /Users.
Xcode starts down again, but this time uses the remaining portion of the absolute path for the file (Xcode never goes back down to /Users because it is the same for both paths).
Xcode continues all the way to the filename, using the Title case username. /Users/myusername/Folder/Foo/Foo/Foo/../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift.
When location is set to Relative to Group, the path to the group is implied, so the previous path simply becomes:
../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift.
Familiar?
Anyways, how do I fix that?????
It turns out that the problem was that I had my home directory path set to a different capitalization than the actual folder.
I want to simplify Visual Studio Find in Files result, and I found a posting.
And I found it is not quite satisfactory.
Is there a way to display partial portion of directory in find result window?
ie)
x:\users\myname\project\solution_home\project1_home\src\project1.cpp
x:\users\myname\project\solution_home\project1_home\src\helper.cpp
x:\users\myname\project\solution_home\project2_home\src\helper.cpp
into
\project1_home\project1.cpp
\project1_home\helper.cpp
\project2_home\helper.cpp
IMHO, filename alone is not enough to distinguish important result, particulary in large soultion.
but, I want to eliminate certain part of directory path being repeated in every single result.
I wish there would be directory depth designation in $d format string.
ie)
$0d : file's directory
$1d : parent directory
$2d : parent of parent
... etc
Is there any extension and/or technique to do this?
PS: sorry for my poor english
I have something of a hack for this problem: map the local path to a drive. For example:
> subst Y: x:\users\myname\project\solution_home
Your Find Results will then be:
Y:\project1_home\project1.cpp
Y:\project1_home\helper.cpp
Y:\project2_home\helper.cpp
N.B. It has the side effect of breaking the CodeLens Team indicators (which must be a bug).
So, is there a possible way to move Test.txt to C:\ProgramData\CsD2\Tools\("Unknown Folder Name")\data\per Using command prompt?
using foxidrives solution for your previous question for detecting the correct directory, then just
move test.txt "%folder%\"
Short answer: yes. Not quite sure what the situation is that has left only the middle part of your path unknown, and the need to use the comnand line, but I have encountered similar cases on Linux and expect the algoirthm can be adapted to Windows commands. It's possible to do this by hand rather than writing a shell script, but it's up to you and your skills.
Permissions matter. Make sure you elevate yours enough to read and write in Tools before continuing.
First, change directory to C:\ProgramData\CsD2\Tools\
Presumably there are many items here. Some may be "hidden," so list the contents of this directory and be sure to include an option to show hidden files and folders. If you can, restrict the search to directories only.
It's tempting to display contents recursively in the above step. It's up to you, but I find it makes the output cluttered without a script to do the rest of the work.
Now it's time to search for the subfolder set that theoretically only exists in your target folder. Suppose Tools contains the directories fldr1, fldr2, and fldr3. Use your command to list a directory's contents with the path "fldr1\data\per", then use "fldr2\data\per", and so on until it doesn't return an error. Per may be empty, but that should look different from the path not found error.
Now you've found the name of your mystery folder. Write it down for future reference.
At thus point, you know the path to Test.txt, and the full path to the destination directory. Do a move command to relocate Test.txt, and you're done. I like to relist the contents of the target directory after to be comfortable that it arrived.
On TextMate 2 and opening two files in two different locations such as /path/1/file.txt and /path/2/file.txt, I am no longer seeing a way to perform diffs as before since one cannot select files in the project "drawer." We now have a file browser that seems to have taken its place and thus no way to pick the two opposing files. This also precludes any other command that requires multi file selection that are not within the file structure.
Am I missing something that would allow this to work properly when dealing with files in two different paths?
This isn't a new trick. It's one we learned when grep in project would go insane when you had a project with files whose common ancestor was root or some directory far above the files. Instead of opening your files like:
mate /foo/bar/baz /quix/quacks/quux
You do the following, assuming you're in an empty directory or don't care that its files will be included in the project as well
ln /foo/bar/baz /quix/quacks/quux . && mate .
That can obviously be wrapped up into a function to reduce the syntactical difference. In fact, at one point, I actually wrote a wrapper script around mate to do that transparently when needed AND clean up the hard linked files after I closed the project or quit TextMate. That went away with some bad hard drive though.
Anyhow I HTH
Due to using both Windows and Ubuntu on my computer I'd like to be able to create documents independently. I have one directory for logos and I want to use them in any documents everywhere.
The problem with different file addressing I solved with those commands:
\newcommand{\winlogo}{D:/logo/}
\newcommand{\linlogo}{/media/DATA/logo/}
\includegraphics{\winlogo logo_bw}
How to provide this feature:
if(parameter==windows){adress:=D:/logo/}
elseif(parameter=linux){adress:=/media/DATA/logo}
else{error}
I've run into this problem as well, and I found that hard-coding the paths is an absolutely terrible idea. Also, keeping these directories in sync will eventually be a problem once your projects begin to grow.
The way I solved this was to put everything in version control (I like git, your mileage may vary).
Then I created an images folder, so my folder hierarchy looks like this:
Working-Dir
|-- images/
|-- myfile.tex
|-- nextfile.tex
Then in the preamble of my documents: \usepackage{graphicx} and \graphicspath{{images/}} which tells latex to look for a folder called images, then look for the graphics inside the folder.
Then I do my work on on comp, push my finished work back the repo, and when I switch computers I just pull from my repo. This way, everything stays in sync, no matter which computer i'm working on.
Treating tex source like source code has greatly improved my work flow and efficiency. I'd suggest similar measures for anyone dealing with a lot of latex source.
EDIT:
From: http://en.wikibooks.org/wiki/LaTeX/Importing_Graphics
Graphics storage
There is a way to tell LaTeX where to
look for images: for example, it can
be useful if you store images
centrally for use in many different
documents. The answer is in the
command \graphicspath which you supply
with an argument giving the name of an
additional directory path you want
searched when a file uses the
\includegraphics command, here are
some examples:
\graphicspath{{c:\mypict~1\camera}}
\graphicspath{{/var/lib/images/}}
\graphicspath{{./images/}}
\graphicspath{{images_folder/}{other_folder/}{third_folder/}}
please see
http://www.ctan.org/tex-archive/macros/latex/required/graphics/grfguide.pdf
As you may have noticed, in the first
example I've used the "safe" (MS-DOS)
form of the Windows MyPictures folder
because it's a bad idea to use
directory names containing spaces.
Using absolute paths, \graphicspath
does make your file less portable,
while using relative paths (like the
last example), you shouldn't have any
problem with portability, but remember
not to use spaces in file-names.
Alternatively, if you are using
PDFLaTeX, you can use the package
grffile which will then allow you to
use spaces in file names.
The third option should do you well-- just specify multiple paths for the \graphicspath I wonder if LaTeX will fail gracefully if you just include all of your paths in there (one for images, one for your logs on linux, one for your logos on windows)?
Mica, thank you once more, your advice works properly!
I've tested this code in preamble, in .sty file it doesn't work:
\usepackage{graphicx}
\graphicspath{{/media/DATA/logo/}{d:/logo/}{img/}}
where
/media/DATA/logo/ is address to directory with logos on mounted partition in Linux
d:/logo/ is address to same directory in windows
img/ is address of images for current document in actual working directory
and this code in document:
\includegraphics{logo_zcu_c} from logo dir
\includegraphics{hvof} from img/ dir`