I am using the perforce gui application P4V (not my first choice, but that's what I need to use).
Every time I close P4V and open it again I have to find my stream in a sea of countless streams, so that I can show my stream as a graph and also switch to the correct workspace.
Is there a way to save my current state when closing P4V so that when I open it again I can continue working with my graphs ready and my previous workspace already active?
Thanks
Update: The issue here was a bug in the 2015.2 build of P4V around saving the state of the stream graph. It was fixed in the 2016.1 release.
Sounds like a problem with the preferences file to me. P4V should be saving all that state exactly as you describe.
How much customization of your preferences have you done? If it's minimal, I'd suggest just shifting the .p4qt folder in your user directory to the desktop or something and establish some preferences again from a clean state and see if the issue goes away.
If you've done a lot of customization already, support should be able to guide you to the specific setting keys in the preference files to remove, it's just fiddly.
Related
A weird one here. I've noticed that the 'Team Development - Sync with On-Disk Project' is not deleting files on my ODP. I'm not using automatic updating.
I've looked at the permissions on the odp/nsf folder, and I've noticed a little grey out checkbox which I can remove, but it pops back up immediately.
I've also tried opening up the security on the folder (right-click/properties/Security) and giving most groups superpowers, but no bananas.
Any help or hint would be appreciated.
Update: the deletions happen, but not immediately. I'm confused.
We have had issues not just with deletion but newly added files received via git, the only solution is to refresh both projects a few times and sync them both.
Another issue: I often lose some project settings, i.e. an additional source folder and a .jar file. It probably has something to do with replication, but it's impossible for me to find out exactly why this is happening.
Currently in our repository, there is a conf/ folder that I have svn ignored so as to avoid committing local configuration data. However, now I need to add a new configuration option to this file. From my research, the only answer that seems applicable is to change the project structure and have 'config.conf.default' files that everyone can add new options to, and they must copy that file to 'config.conf' and edit it with their local options and svn ignore it. As this is not my project I am working on I would prefer to find a more 'local' solution if their is one.
Changesets don't seem to be helpful in this situation, and constantly manually backing up, reverting, remaking changes I want sync'd, committing and then restoring each config file doesn't sound fun at all.
I read some posts that TortoiseSVN 1.8+ can do this sort of thing, I'm hoping there's a Linux equivalent.
Looking forward to any advice -- thank you
I do not know for certain, but I will be very surprised to hear that TortoiseSVN can do this. What you are asking for runs counter to everything that SVN (and, I might add, any other version control I'm aware of) works.
A file can be either tracked, in which case any change to it is an interesting change, or untracked, in which case none are. Allowing partially tracked files means the version control cannot know whether the change you just made should or should not be tracked. Allowing this is just asking for trouble.
While, technically, TortoiseSVN might have such a feature as an overlay above SVN, in my experience, that's simply not how Tortoise is built. Their design is very nice in that they are simply an SVN client, honoring the same configurations and semantics as the command line tool (for both Windows and Linux). In fact, the fact that Tortoise, the command line tool and the VisualStudio clients all share the same mode of operation is one of the strong points of the tool set, making the experience of working on Windows just a tiny bit more bearable. I really hope Tortoise have not decided to deviate from that.
On my VS2012 I noticed that if i edit a file that is not checked out in a notepad and save it, in TFs it will be marked as checked out and edited. So far we haven't found too much of a problem of it, but potentially people can get careless and make/save changes unintended.
Is there anyway to turn off that feature?
What you're seeing is now default behavior for Local Workspaces. One way to 'undo' this is to set your workspace to a server workspace once more. But I suggest you first investigate the benefits of local workspaces before deciding to turn it off. People still have to check in files, so there is a gate between changing the file and actually committing them to source control.
I forgot to check out a source code file before modifying it.
When I get last revision, Perforce overwrote that file, so my work is totally lost.
Is it possible to recover the file?
For future use, update your client workspace so that you specify "noallwrite, noclobber". If noclobber is set, Perforce will not overwrite your writable un-opened files: http://www.perforce.com/perforce/doc.current/manuals/cmdref/client.html
Only if your editor or your operating system saved a copy or it's been modified long enough that it made its way to your backups. Perforce will not make copies of such files, it blindly assumes that you didn't lie and will always honestly tell it when you want to edit a file.
if you are using eclipse then its possible to retrieve the local version using Compare With -> Local history . It helped me.
This has happened to me recently. For some reason, after I "p4 sync"-ed my workspace, and do p4 resolve, I noticed that my changes to a file were missing. I'm not sure if my changes were not saved or I haven't checked out the file. But I really remembered that my changes were saved. :(
I have been using Visual Studio for development and it doesn't have local history unlike in Eclipse. Luckily, that file is a javascript file and I have been testing my application in Internet Explorer. Since IE does some caching on some internet data like js files, what I did is to check the directory where it saves temporarily files (Internet Options -> Browser history settings ) there you'll see different versions of the files saved. I did recover my files! It was really just luck!
After that incident, I installed a plugin for visual studio for storing local history of files everytime it's being saved. http://visualstudiogallery.msdn.microsoft.com/226c2108-9da9-407d-b90d-9783040d27b8
Best thing to avoid these cases is to:
branch out your files first into a separate devline during development and submit every milestones you accomplished
incrementally. In this way you'll always have versions of important
changes you do during development. After this you could
integrate it back to the parent branch/mainline.
http://answers.perforce.com/articles/KB_Article/Branching-Codelines-and-Merging-Changes
Hope this helps!
If you fired the following command (which is a FORCE sync option), only then will Perforce update ALL your files.. including ones which are WRITABLE. The only exception is that any file that you have OPENED in perforce will not be overwritten. So if your file was made WRITABLE using OS command, and not using p4 open.. they will get overwritten by p4 sync -f.
p4 sync -f
The other possibility is that you did p4 sync, and still perforce overwrote your writable files (which were not opened using p4) because your workspace settings don't have noallwrite, noclobber specified. Usually by default, these settings are already specified, so that Perforce doesn't clobber writable files.
My home Perforce server died. I set up a new one.
The project I set it up to support died in the planning phase. The contents of the depot at that point were some prototype code and we never got to setting up a disaster recovery plan.
The dev machines still have the existing code on them. As much as possible, I'd like the change of servers to be transparent to the developers--use the same depositories and the same directories, just change the name of the server to connect to and get back to work.
What do I need to do in order to make this happen?
I assume you don't have access to the perforce depot files from your dead server? I assume you know that you will lose all your history.
If that's the case all you need to do is setup the new server, create a user / client with the same root clientspec path as your original clientspec was using on your dev machine and checkin all the files into perforce. Pretty simple really...
You may need to rebind is SCM binding that you may have in tools like Visual Studio but that's about it.
What Shane suggested will populate the depot with one person's version of the files. But if you have another user who also has a copy then you'll need a couple of extra steps.
Firstly, just set one machine up as suggested by Shane.
You now need to get the second user set up. If you are confident that the version of the code user 2 has exactly matches what you put in the new server, then just create a client spec (probably same name as used before), and then sync using the "Force" flag. This will overwrite all the files on user 2's machine, and - more importantly - ensure Perforce knows which versions you really have.
However, if you are in any doubt as to any differences in code, then do not do the initial sync from the second user's machine. Instead, set up the client spec, then use the "Reconcile offline work" option - from P4V select the workspace, then it's a right click option. Then just walk through the subsequent dialog to sort out what you need.
Finally, if you want a very quick & dirty backup system for your server, I've posted some notes on my blog here - should take you just a couple of minutes to set up.