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.
Related
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.
I have a owncloud server and the owncloud desktop client.What I want to do is to be able to delete things server wise and have it automatically delete from the pc. The problem is that the owncloud client displays a warning message of "Remove All Files"? with the choices of Remove all files or to keep files when the files are deleted from the server. Is there a way to not have the prompt come up and automatically remove all files?
In the version 2.2.3 (maybe earlier), you can change the configuration file to disable the prompt.
See the code where the prompt is invoked and the code showing the configuration file property.
If you edit (on Windows): c:\Users\myuser\AppData\Owncloud\owncloud.cfg and add the following, under the [General] section, you will no longer get the prompt.
promptDeleteAllFiles=false
The short answer: You cannot change this currently.
The long answer: The dialog was added as a safe-guard because there were cases where you could lose all your files unintentionally, e.g. if your admin re-created your account and left it empty. The client would assume the files had gone and would replicate this (it could not know better), so it would replicate the data removal locally. The code is still there today just to be safe.
If you are fearless, you can patch Folder::slotAboutToRemoveAllFiles(). Alternatively, you could open a bug report so we can solve this for everyone. What is your motivation to be able to do this without a prompt?
PS: The sources can be found on GitHub. URL and build instructions at http://doc.owncloud.org/desktop/1.5/building.html.
I have a script that processes the files that someone drops into ownCloud and it will then move them to the final storage place. However, this prompt stops the client from syncing until I manually log in to acknowledge it... I guess I will learn how to patch this.. Dropbox doesn't do this. Google Drive doesn't do this. But since I can't use cloud services (compliance issues), I have to use this solution until I can build a new secure upload means.
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
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.
When using p4v to sync a project onto a 2nd machine I was surprised to see that files I had checked out on my primary machine were not included in the "Get Revision" (Get Latest Revision and Force options selected).
This seems like an elemental thing to get working but I can't find how to force this other than perhaps tagging the source tree and getting that, which I don't want to do if I don't have to. . .
This is an elemental thing. Syncing on one computer is in no way influenced by what you have open for edit on another. Syncing retrieves all those files regardless of who has them checked out, unless you have confused the server by messing with files outside the Perforce client. However, you said you used the -f option, which would solve that problem.
Are you sure you don't have those missing files open for add and not for edit?