Jul 072014
 

During a server move relatively recently, we decided to go about it by setting up a replica in the new site, then switching it to a master once everything has been replicated over.

It was a pretty solid plan. Unfortunately, something went wrong and the replica was missing revisions from it’s versioned files. This resulted in librarian checkout errors when trying to sync the missing revisions.

I still had the files from the original server, which contained the missing revisions, but unfortunately work had continued on many of the affected files, so we weren’t able to copy them over verbatim. I searched around, but to my surprise there wasn’t a utility for recombining revisions for RCS files. Perforce support also didn’t have one, again to my surprise.

I wrote a small utility here that recombines versioned files. It uses rcs to do much of the work, so that will need to be installed on whatever system you are using. The rcs-combiner acts on individual files, while the merge-p4-roots.sh script is a simple script that combines two perforce roots together.

Rather than running it against full p4 roots, I advise pulling out the specific versioned files you need to combine by examining the output of p4 verify -q, and piping the missing file#revisions into p4 -x- fstat -Oc to determine it’s lbrFile (also known as the versioned/RCS file). As always, YMMV, and I take no responsibility if you try to run this against a live server and end up breaking something.

Sep 272013
 

This was a pain. Our backup software was unable to read certain Perforce versioned files from the P4ROOT (mostly .gz files). Obviously this is a fairly big issue, as it prevented us from creating any useful backups.

I checked the access control lists, ensured SELinux was disabled, and even gave the files in question 777, and still I could not read from them. We even tried running fsck multiple times with the most rigorous checking we could enable. Nothing seemed to work.

Luckily, I had top open in a terminal while I was mucking around and trying to read from the files manually using dd. The system was idle until I tried accessing one of the files, at which point a process called “nails” appeared for a second or two. Curious, I looked into it a bit further. The damned thing was a McAfee virus scanner! After disabling it, everything started working perfectly. The fact that it was only doing this on .gz files should have been a dead giveaway that a scanner was at fault, but then again I’d never encountered a linux system with a virus scanner installed.

Lesson learned.

Jun 272013
 

Twice this month I’ve run into the situation where one of our db.* files got corrupted, and started throwing “BTree is corrupt!” errors on various commands. The first instance was caused by our system running out of main memory, and reaping p4d processes while they were writing to the database tables. The second instance was caused by exhausted disk space.

Recovery was fairly simple in the first instance. I simply recovered from the last checkpoint, and replayed the journal overtop as per the documentation:
Continue reading »

May 102013
 

I’m currently in the process of resizing a partition in Solaris 10. So far, the instructions that I’ve found have been quite incorrect, so I’m documenting the steps I’m taking here. In my particular case, I’m resizing a single partition on a non-root disk after increasing it’s size through VMWare.

Continue reading »

May 072013
 

Ran into this little gem today… I’ve got a project that I’m currently trying to branch. It’s a very simple integration operation from one location to another, nothing crazy. Of course Perforce needs to make it as complicated as possible by throwing me this error for a couple of our files:

cannot submit unicode type file using non-unicode server

Now, this is incredibly nonsensical. I’m integrating an already submitted file from one location to another, and checking it in. Why does Perforce reject it if it’s already been submitted successfully once before?

It turns out that the way perforce handles unicode filetypes changed at some point. Before this change, you could submit unicode files without any problems. After this change, your server needs to be reconfigured as a ‘unicode server’ in order to check in unicode files, even though it’s clearly handling already checked-in files just fine. To me, this seems like an artificial restriction, but I digress.

To resolve this, you just need to reopen the files as text, and resubmit them.

$ p4 reopen -t text 

After that, you can work on the files again as normal. I’m not sure what effect this has on the encoding of the files themselves, so as always, YMMV, but at least you’ll be able to get on with your life.

Feb 142013
 

I recently did a migration of source code from one perforce server to another. During the merge process, I ran into an odd warning:

perfmerge++ warning:
        No mapping for change 293174 in database /x/sourceserver/server/. Rejecting.

Thinking that it was just a dead or missing changeset, I skipped right along and proceeded to put the server into production. Verify came back ok, so I figured everything was fine.

It was not…
Continue reading »

Nov 222012
 

Jenkins makes adding slaves really easy. For unix machines, the preferred method is to use SSHD, which only requires that the master be able to contact the slave. On windows, however, you are stuck using a JNLP based solution, which requires that the slave be able to access master over the network.

I got stuck in the awkward situation where I had to add a windows machine to our master, but the slave could not even ping it. This could be resolved by updating our routing tables on the slave side, but unfortunately that wasn’t an option here. Instead I chose to try and start the slave using a Windows SSHD solution.
Continue reading »

Aug 232012
 

Here’s a script I whipped up in order to send an email to all recent Perforce users. I needed this because my company uses a shared license, so all user accounts are shared between our perforce servers. When a server needs to go down for maintenance, I like to email only those people who actually use it. This uses python, but it does not require the p4python api (though I imagine it would be quite simpler using it). I’m sure there are some imports that need to be cleaned up, but whatever, it’s just a quickie.
Continue reading »

Jan 232012
 

I often find myself in the situation where I need to delete the perforce account of a user who has left the company. Unfortunately I’m usually unable to do so because they have left files open, resulting in this error:

$ p4 user -d -f SOMEUSER
User SOMEUSER has file(s) open on 2 client(s) and can't be deleted.

The solutions posted online usually involve either deleting the clients, or ‘masquerading’ as the client host and reverting the files by hand. This is very tedious, so I wrote a python script to do it instead. It’s a bit crude, but all it does is take usernames off the command line, and proceeds to revert all the files that user has open on the server.

Continue reading »

Dec 022011
 

I recently upgraded my work PC from Natty to Oneiric, and discovered that whenever I had a window open that wasn’t maximized, it’s backend process and xorg would use up 100% of the cpu.

I was nearly about to rebuild my machine when I discovered that it only happened for non-maximized GTK windows. As a last ditch effort, I ran gtk-theme-switch2, and switch my theme. Magically, this fixed the problem!

Part of the issue was that I’m running in Fluxbox, not Gnome or Unity. I think somehow it got the theme messed up during the upgrade, and since neither Gnome nor Unity had the chance to set it to a correct theme, it borked.