I have a large software project that some folks have just started dumping things into (instead of creating a development branch!!! ARG!!) incrementally as they make sweeping changes. There are problems with some of the things they did, and of course they are on holiday. So I used Perforce to try to get the baseline at a particular point in time. Perforce claimed to get all the files at that point in time, but it did not build. I know that it did build originally, as our CruiseControl successfully built it at that point in the history.
So obviously something is wrong with Perforce.
Below is some fabulous ASCII art showing the structure of the checkins to Perforce. Letters indicate different developers, numbers indicate their checkins.
Newest
D 18
D 17 Changed the contents of the files in D 16
D 16 They did some `move/delete` and `add/delete` here
D 15
D 14
D 13
D 12
C 1
B 2
D 11
D 10
D 9
D 8
D 7
D 6
D 5
D 4
A 3
A 2
D 3
D 2
D 1
B 1
A 1
Oldest
D18 doesn't work. D17 does, but I want to test at B2 to simplify things.
C1 is the CruiseControl version that built and ran just fine when it built last week. It only changed the version number in a text file. No big deal.
I want B2, so I do a Force get at B2. It doesn't build, even though it did when I checked it in. So I remove all the files and do a Force get at B2. It still doesn't build. I wondered what I could have done to it, and finally decided to try to get even earlier.
If I go all the way down and get A1, it builds. I can then get B2 and it will build (even if I delete all the files from A1!!). I can keep going up until D16, which does not build. D17 does build. The interesting thing is when I go up the tree, from oldest to newest, B2 builds and runs fine. When I go down the tree from D16 or newer, B2 does not build nor run. If I start at A1, and go up the tree to D15 and then go back down the tree to B2, it builds and works. Once I have gotten D16, nothing older builds unless I go all the way back to A1. I don't understand the linkage/problem. There seems to be no connection between A1 and D16 at all. A1 is a simple data file change which isn't even compiled. A1 was before these guys started dumping sweeping changes into the baseline, but even then, I expect Perforce to be able to replicate a changelist the exact same moving either direction in time.
I have been operating under the impression that if I do a "force get" on a particular changelist, then I will get --everything that was checked in at that point in time (yes, I understand you can ask Perforce to only give you that changelist's files, but I did not do that).
I have nothing checked out in this repository.
I delete all the files each time.
I do a Force get every time.
I can build now, but I want to be able to trust my configuration management tool. What am I missing? What other information can help to debug this?
Edit about my environment:
Windows 7 64-bit
Perforce Server 2013.1/628821
Perforce Visual Client/NTX64/2013.2/661179
Using QNX Momentics 4.6 to cross-compile to QNX 6.4.1 for x86
Additional Update:
While this is probably not exactly related, I just ran into a situation where the GUI, P4V was confused and made it look like the backend was confused, when it was not.
There was a file that the GUI claimed I had edited and removed one line, when I had not. I did a force get latest, and it still looked like it. I deleted the file, then got the latest, and it still claimed I had edited it. I closed P4V and reopened it, to find the file was as I expected it to be. Somehow, the GUI got confused. So the takeaway is: if it looks weird, restart the GUI and see if that helps. Maybe this could have helped with my issue above.
Related
We have Swarm-Perforce integration enabled and I have requested a review Y on a shelf A. I have gotten a few comments and have changed/added files and created a new shelf B (I do not want to replace A because I may want to come back to it). Is there any way to include shelf B to review Y?
One way I thought was making a copy of A and then replacing A with B. Is there a faster way to do this?
Yes, there's a faster way. Just replace the shelf in A.
Swarm keeps all the versions of your review. When you first request the review for A, it creates version 1 of the review. When you update the review (or re-shelve), it creates version 2 of the review. Etc. There's a horizontal slider in the Swarm review GUI, where you can navigate all the versions the review had.
Now the good thing: each of these versions is "implemented" using a Perforce shelf (in another workspace, managed by Swarm). Thus, you can always access and unshelve all the review versions. (You can even diff your versions using the two-dot button in the Swarm GUI.) To unshelve a specific version of your change, pick that version with the horizontal slider and then copy the shelf number where it says Change 1234 shelved into .... Copy the 1234, go to P4V, Ctrl-G, open change 1234, unshelve.
The current head of a certain project I am working on is changelist 123 and has files C, D and E.
9 submissions ago the code was completely refactored, hence, 10 submissions ago, let's call it changelist 11, the project only had files A, B and C (C being totally different from changelist 123 version of it, ofc).
Stuff happened and I had to branch from changelist 11. I now have to submit the code, and my submission will be the new head.
What I am not sure is how to integrate so that all and only files from changelist 9 are present in the head after my submission (that is, all the fiels in changelist 123 are "deleted").
I've tried looking for solutions but I clearly found the wrong info, as I was being required to manually delete all the files... The project, clearly, is not 3 files only, and with git you can do this pretty easily, so I assume there is a proper way to do this in perforce too.
Any hint is appreciated, thanks!
EDIT:
Maybe clearer is to say: My head is 123, I want to branch (in a tree sense) from revision 11 and create revision 124, which will now be head. As such, when I submit the project head in the depot will not contain any file/changes related to revisions 12 to 123.
There are many ways to accomplish this, but the easiest way is to use P4V. Right-click on the file and choose Rollback... and select "Rollback file to: Revision" and enter "123". Then click on the "Submit..." button.
I've googled this, and saw that someone had a similar problem here -> stackoverflow, but as luck would have it, unresolved.
I have an issue where my P4 client is not able to see or access any submitted files that are newer than 4 months old.
Background - My root directory/db files are on D drive which is undisturbed. I got a nasty virus yesterday, so I checked in all my workspace stuff and recovered to a December drive of my OS. Now that I've successfully booted up in my December version of my OS (where the same version P4V and P4A is already installed), my P4V is only able to see and access files up to 12/15/2015 - nothing after. The drive image I recovered from is dated 12/19/2016. Yet, I can physically inspect all my post Dec P4 checkins in the physical location of my DB on D drive. It's ALL THERE.
Here's really interesting info - out of curiosity, I recovered back to my Virus laden OS from yesterday. Opened up P4V, and it is able to see and access all my files up till my very last submitted file which was checked in yesterday.
Other important into
- The depot, stream, and workspace that my p4 is using is the same between my recovered Dec recovery OS, and yesterday's Virus laden OS. Nothing was ever changed in my P4 settings.
System info:
Windows 10
P4V and P4A - NTX64/2014.3/1007540 (for both my recovered windows image from Dec, and yesterday's virus laden windows)
P4 is my achilless heel. Help appreciated. I will not take offense if you explain things to me like a 3rd grader.
Cheers,
Paul
First off, I used incorrect terminology in my original question. I had my depots on D drive and everything else in their default locations on C.
Where I had it wrong: in the belief that as long as I had my depot files backed up to a safe location, I was protected. There is more to it than that :|
What went wrong: When my PC crashed, I recovered to a 5 month earlier December version of my Windows install which means (obviously) I have December's install of P4 with database files only aware of files I checked in up to December. I did indeed have 1000s of files check in after Dec, all alive and intact, but P4 is simply unaware of it. An assumption (which I had) that P4 simply peeks into the Depots to stay up to date of their contents is an incorrect and dangerous one.
To those who may benefit: For those do-it-yourselfers, these are the 2 things in Perforce you should be backing up if you want to be able to do a full recovery later down the line when things go bad:
Database files. By default, they live in the Perforce application’s “server” directory. For me, there are 67 database files in my C:\Program Files\Perforce\Server. They are all prefixed with db.* and it’s these files that P4 uses to “know” the current state of things, like, your changlists, checked-out files, all your workspaces and their settings, depots and their settings, etc, etc etc. Oh, and what files you even have in your depot! Unfortunately, when backing up database files, you can’t just copy/paste them, but must use command line commands to properly generate 2 other file types (journal, checkpoint) specifically for recovery purposes. It is these files that you'll generate new database files from in a recovery operation.
Depot directories. Depots specify directory trees that your files get stored to, and checked out from when working in your workspace. Files stored here won’t be in their native format, and non-binary files will have their contents tweaked on top of that. Depot directory trees can be manually copied/paste to a backup location.
Proper backup/recovery information can be found here. Like many things, it’s simple once you understand it, but reading this is a bit of a mouth full. It would have helped me to just see slightly fleshed out sample commands along with the reading material, so I’ve included some here. These are the bare minimum command line commands (plus other manual stuff), and will recover a checkpoint, not checkpoint + journal (again, take a look at the link to get a better understanding). Also, I would recommend practicing backup/recovery in a safe throw away environment (or throw away assets) to get the hang of this before doing it for real.
---------- Backup ------------
Despite all the material in the link, it only takes a bare minimum of 3 command line commands (plus other non-command stuff) to do a proper P4 backup, and 1 cmd (among other things) to recover on my end. Again this is only a partially fleshed out sample to illustrate what the command prompt portion of backup/recovery looks like. There is a little more to it than simply running these to get you where you want.
(note: On Windows, you may need to start a windows command prompt as administrator)
>p4 set P4USER=superuser_name
>p4 -q verify //...
>p4d -r "C:\Program Files\Perforce\Server" -jc <yourBackupDirectory>\<prefixOfYourChoosing>
---------- Recovery ------------
>p4d -f -r "C:\Program Files\Perforce\Server" -jr <yourBackupDirectory>\<prefixYouChose>.ckp.1
In my case, I had to use the -f flag due to errors when not using it.
Cheers,
Paul W
I have Cygwin installed on 2 different drives (not sure why!) C and D
C is full proper version I want
D is some sort of copy.
BUT Cygwin appears to default to D. I know this because it uses the .bashrc from D not the C one.
Where do I tell Cygwin that I want it to point at the C version? Without reinstalling everything?
Well, this would all depend upon how you are starting your shell. Likely you are starting it by opening a shortcut to something called "Cygwin Terminal" or possibly "Cygwin64 Terminal". If you look at the properties of the shortcut, you can see which one it is invoking. If you want to invoke a different one, change the drive letters and path in the shortcut properties.
As an aside, having two installations of Cygwin, even on two different drives, is almost certainly a bad idea. You can have multiple installations if you know what you're doing, but it's not recommended.
Let's say I'm at state A in my document. I then make changes B, C, and D (in order).
Is there a way I can keep changes B and D, but skip C?
Or, let's say I'm at state A in my document. I make change B, undo it, and then make changes C and D (so Vim has an undo tree with two branches). I then change my mind and decide I want to use B and D but not C.
How can I do this in Vim? I have the gundo.vim plugin installed, but I haven't used it that much.
Well, I'll take a stab at this and say: No, I don't think there's a way to do exactly what you want with vim.
gundo.vim adds a nice interface to vim's undo, but doesn't change its core capabilities. So I took a look at the official vim docs to see if there's any hints to whether it is capable of this:
vim docs: undo
User manual page about undo
Nothing about merging two branches together. I think ewh and ZyX are right: to get a general solution for merging B with D, vim would need either for
Bram to add it as a separate feature in a future version
someone to implement it in a plugin by integrating with something that can already do merges (like git/hg)
You can of course try to do it manually by having files with versions B, C and D as well as a few diffs open.
Note: If I misunderstood and you weren't wondering about a general solution and are looking for help with a specific instance of this, let me know and I'll see what I can do :)
Is there a way I can keep changes B and D, but skip C?
You're at state D. :w file.ext_D
Backtrack to state C. :w file_ext_C
Backtrack to state B. :w file.ext_B
:!kdiff3 file.ext_B file.ext_C file.ext_D
This gives a 3 way merge of the differences, but still you'd have to manually go in and choose every red line in D for each merge conflict. Not exactly an easy solution.
If instead you do
:!kdiff3 file.ext_C file.ext_B file.ext_D
Then the merge happens automatically (except for individual lines with multiple changes)
For more complicated scenarios it gets tougher.
Note: I'm not sure how a revision control tool is much help. You're basically doing something like creating a patch between B and D, and then subtracting the patch from C to D from it. It seems to me that revision control systems are usually designed to manage merges between different sources of changes, not changes along a single branch.
kdiff3 is available at: http://kdiff3.sourceforge.net/