Perforce
Wow, it’s been a long time since I last posted. Actually, in all fairness to myself, I have been doing quite a bit of blogging over these past couple of weeks. However, it’s been on my other blog that is only internally accessible to those who have access to the Sun corporate WAN. I’m still debating whether or not I want to merge that blog into the public realm of owenkellett.info. As I mentioned in a previous post, Sun encourages their employees to blog and has a system for setting up both public and private blogs. Considering all of the privacy concerns and media attention given to certain individuals at companies like Google and Apple who have been fired for disclosing company secrets on their blogs, I thought it would be easier to simply keep my work-related blogging internal to Sun’s network.
While it is usually not hard to judge what is and what isn’t suitable material to publicly publish, it is considerably simpler to just privatize everything. On the other hand, I am certain that nothing I have blogged about thus far would reveal any company secrets or proprietary information. Thus perhaps I need to rethink my blogging strategy. I am considering trying to implement a “multi-blogging” system where I can feed blog posts to owenkellett.info, my internal Sun blog, or both. Although, I am not particularly fond of the software used by Sun (Roller) as it is buggy and not as robust or feature rich as WordPress. In any case, it is for posts like this one that such a system would be useful as it is suitable for both of my blogs:
As I’ve been becoming more comfortable with my responsibilities at Sun, I’ve also been growing more accustomed to the tools that they make use of. In particular, I am growing increasingly fond of Perforce, the version control system that we use. Previously, my only exposure to version control has exclusively been CVS, which I have used in a number of projects in the past. For the unititiated, version control software is a tool that coordinates the concurrent modification of a source code by multiple developers. Thus for example, if Joe Programmer and Cathy Hacker are both working on different segments of the same source code file, the version control system helps to cleanly integrate these modifications and all modifications made by a number of users at once. The general mechanism used to do this is by keeping a centralized repository of the source tree on a server, and each user checks out their own individual copies of this tree. Users than make changes on their individual trees, and check them back into the central server when they are finished. The checkin process controls the merging of individual files to keep the source tree clean.
There is no doubt that CVS is very powerful, featureful, (and also very free). I am no expert of either CVS or Perforce, but I have noticed a couple things about Perforce that make it “safer” (probably the most suitable word to use):
- I seem to distinctly remember a situation using CVS when I made changes to a particular file, and then perhaps stupidly did a “cvs update” before a “cvs commit.” The result was the version of the file in the repository clobbering all of my changes. Perforce forces you to explicitly “p4 edit” every file that you want to modify. Therefore if you sync up from the repository before submitting your changes, it won’t overwrite all of your work.
- Perforce submissions are stateful. When committing changes to a CVS repository, if something screwy happens to your connection or the server mid-update, you could be left with a bunked repository. This can’t happen with Perforce as “p4 submit” operations are atomic.
On the other hand, Perforce costs money. I really need a lot more exposure to both systems to make any real assessments as to which one I prefer. However, these are just a couple quick things that I noticed that I thought were worth mentioning.
November 1st, 2005 at 6:50 pm
whoa! secret blogging!?!