I have a network mounted drive and as a result if I right click anywhere it hangs for awhile. this is because TortoiseSVN is trying to read the local .svn repo. Is there a way that I can prevent this from ever happening for certain local repos? Say perhaps I can have TortoiseSVN not open for files under the W:\ drive?
The icon overlays are already turned off (by default) because W:\ is a network drive. But when I right click anywhere I can see a large file transfer occur for the .svn folder everytime.
Well this was easy to find via the settings. I just assumed it wasn't there initially but for such an established program it makes sense that this would already be a feature:
Related
I have a Synology NAS (DS1621+) in my local network. A shared folder XXX is crated with SMB3 and SMB2 MTU enabled. The "Enable Recycle Bin" option is also activated for this shared folder. And I can see there is a #recycle directory in this folder.
In my Windows10 Pro, I connect to my NAS by using "Map network drive" in Explorer. But when I try to delete something in this shared folder, it always makes a "delete permanent", and the recycle option is in gray (see image below).
I've learned that SMB protocol supports truly the recycling functionality. So how could I fix this problem?
Thanks for your help.
Solution
After searching in a Chinese forum, I find out that this is just a graphical misunderstanding. In fact, the file is NOT permanently deleted when "Enable Recycle Bin" is activated on NAS. It will be moved to #recycle directory on your shared folder, and you can access it through Synology DSM. So, you can delete any files in Windows on that SMB share without any worries about permanent lost. But in Windows, it always shows a warning panel of "permanent delete" when you do a removing action.
If you want to deactivate the warning panel of permanent delete in your Windows, you can go to your user foled in C:\Users\{username}, choose a system default folder, for example "Downloads". Right click on this folder, go to "Location" tab and change the location to your SMB share. In this case, the files you that you delete will be showed in Recycle Bin on your Windows desktop as usual.
References
简化操作：Win10删除群晖NAS文件不再显示【删除对话框】，Del即删除
From a windows point of view, every delete on a network share in permanent (not in windows recycle bin). It can't know that the NAS will do the move to its own recycle folder.
What I want and achieved so far:
I want to create a custom vagrant box including a configuration and an application to reuse it in different client or serve environments.
Specifically I managed to create vagrant box, based on Ubuntu (precise/64), that has node.js installed, and package it on my dev machine with
vagrant package my-box --output filename.box
I am able to copy the filename.box to a remote server and vagrant up the box there. Node.js is installed within the vagrant box as expected.
The problem is, that I am not able to package the files in the synced folder vagrant. After starting the box on the remote server, the synced folder is empty
Therefore the application I developed on the local machine is not included in the box.
I tried to find a solution or any information about this behavior, but apart from this unanswered Post i couldn't find anything on the net.
My questions:
How can i preserve the files in the synced folder and package them in the filename.box for reuse in the server environment.
Is this even possible? Is the behavior I see a bug or is Vagrant not meant to package the files also?
I didn't do any configuration for the synced folders so far. Is it possible to package files from a different synced folder than the regular /vagrant?
If this is not possible at all, what are best practices for deployment or reusage of vagrant environments including applications?
1-3) No. This is not possible and not intended to work in the way you expect it to work.
Think of VirtualBox's shared folder as a mounted volume on a remote machine. It's not part of the file system of your virtual machine. The actual data is saved on the host machine, not the virtual one.
4) If you want to add data into your box, just copy your data over to the vm before you pack it. No need to use shared folders.
You cannot package a synced folder but what you are desiring is absolutely possible.
The easiest way to accomplish this is to put the data in some other directory in the box (thus ensuring it gets packaged with the box). And during the Vagrant box's provisioning, move or copy the data to the synced directory.
Once the box is up and running, the synced directory will have the files you want in it.
I hope I'm not asking a question that's already been answered, but I can't seem to find one that fits my situation.
Scenario: Using P4V gui (2011 version), with no access to P4 command line, on Windows 7.
The setup: A user creates a workspace in Perforce from Machine A, pointing that workspace to a shared network drive, and checks out a file for editing.
Machine A then dies before the user can check in the file. The user is then assigned Machine B, for which he must create a new workspace (which is also pointed at the same shared network drive).
The problem: The problem we're having is that even though the workspace from the dead Machine A and from the new Machine B both point to the same location, Perforce considers them to be different workspaces and prevents the user from checking in/submitting the previously checked out file.
Any suggestions on how to check in this stranded file would be greatly appreciated. Thank you very much!
To be nice and clean, I'd suggest this:
Make a backup copy of the file as it exists on the shared network drive.
Connect to the depot from Workspace A (can be done from Machine B if the workspace isn't bound to Machine A).
Revert the file - this will overwrite the file on the drive with the version in the depot (aren't you glad you made a copy first?).
Switch to Workspace B.
Check out the file.
Copy the backup version over the file on the shared network drive.
Check in the file.
...and if you're not planning on using Workspace A anymore, I'd suggest deleting it.
Have you tried clearing out the Host field? For example, see 'Using the same workspace from different machines':
http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.configuration.html#d0e1720
As an update from my comment response, if you need to change ownership of a changelist, the steps are documented here:
http://answers.perforce.com/articles/KB_Article/Changing-the-Owner-of-a-Pending-Changelist
Recently our development team received new pc's. In an effort to make this transition smoother, I would like to be able to explain to my co-workers how to continue using the client they already have set up to pull files to and from the new pc while eventually ignoring the old pc workspace altogether.
I know about adjusting the attributes of the client itself and allowing the client to be accessed by different hosts. What I'm looking to do now is update the perforce have list for the given client to reflect the files (or lack thereof) that are on the new pc's file system (in the correctly mapped location, obviously).
I'm not sure if it is possible with the p4 flush command for perforce to know which revision of an existing workspace file i have without explicitly telling perforce which revision it is...? (this seems like its asking a lot)
Apart from files that Do exist in the workspace, is there a command that will update the have list to #0 for files that don't exist in the workspace?
OR
Is the sledgehammer approach:
submit any pending changes in the old and/or new workspace
remove any files that may have already been forced into the (new) workspace
$:p4 flush [workspace root]/...#0
appropriate in this situation?
If using the existing workspaces is an option, then this should be pretty easy. It sounds like you already know how to make a workspace accessible from a different host (you can leave it blank to make it accessible by any host). If you copy the workspace folder to the new PC, and update the root of the workspace as necessary, it should "just work" without any additional changes.
If I'm understanding your question correctly, I believe that using a workspace name as your revision modifier will do what you want. For example p4 flush //depot/path/some/file#workspacename. For new machines, we often go through these basic steps to avoid having to resync files.
Copy the files in the workspace from machine 1 to machine 2
Create a client that matches the old client's mappings
In the new client, run:
p4 flush //depot/...#oldclientname
I've just set up Perforce on my home computer so that I can work at home without having to lug my work computer around.
I used the same workspace as the one I use at work, but when I try to get the latest revision, I don't get all of the files. Some subfolders are missing despite being mapped like this: //depot/some_folder/... //My_Workspace/some_folder/... some_folder has a subfolder some_subfolder but my workspace didn't pull that folder in for some reason... None of the other lines in "View" have anything to do with some_folder so I don't think they are the issue.
Anyone have any ideas?
The Perforce server tracks what files you pull in your workspace. This is done for speed, so when you do a "Get latest revision" it will only pull the files that need to be updated. Since you are using the same workspace, Perforce thinks you have them in sync already. You have 2 options.
Use p4 sync -f //files/... (If your using p4v, right click->Get revision, then in the options click the Force checkbox) This will tell perforce to sync everything to the latest revision. But then you will have to use this option at work and home, since Perforce will now think you have everything in sync, when really only the files at home are in sync.
Use a different workspace for home and work.
In the GUI, instead of doing the get latest, try doing the context menu for "Get Revision...", and in that window that comes up, check the "Force" checkbox and give that a try.
Create a different workspace to use on your home computer. Do not try to use the same workspace on two different computers unless they're pointing at the same underlying filesystem.
In my case, I have to get the latest into a different folder. I renamed the folder from original workspace, but it did not work if I do a get latest. I created a different workspace, and it worked.