Pvcs Version Control

Extracted from ExtremeVersionControlDiscussion: ...there are some horrendous version control products out there. For instance PVCS, which started out as a really nice little product similar to SCCS (wasn't it based on RCS?) for MSDOS-based programmers, was doomed once Polytron sold it to Sage/Intersolv/Merant. When interviewing, run away fast from companies that use PVCS -- only slothful organizations would put up with how badly it supports simple but effective development processes. There are other really bad products too, but PVCS boggles the mind it is so awful.

I must take exception to this. Granted, it's been a year since I used PVCS, but it was okay at that time. PVCS supported platforms, merging, et al. What's not to like? -- MartySchrader

Like memories of the pain of childbirth, my memories of the horrors of PVCS have faded. The litany for PVCS Dimensions (a newer product that stores items in Oracle) will be different from PVCS Version Manager. The common problems are poor user interface design and an unresponsive vendor that would rather send boxes of schwag for underlings and bottles of Dom to decision makers than fix a bug.

PVCS Dimensions problems

Clunky, non-intuitive user interface requires plunging deeply into the 50MB of documentation in 28 PDFs to perform simple tasks. RTFM is fine when the FM is reasonably sized for the topic. Revision tracking is easy and shouldn't be so painful.
The online help system is straight from the lunkheaded school of menu-oriented documentation, with such useful information as "update item - use this operation to update an item." Thanks. What does "updating" an item mean?
Dog-slow retrieval.
Apparantly, no way to get only things that changed since my last get. (This might be be a failure of discovery on my part... see items 1 and 2, and it's only a big problem because of item 3.) Nope, there's no way to do it within PVCS VM either. Best you can do is script it by listing all versioned files, then do a vlog on that list and specify the "changed since" date, and finally use the output from vlog to generate the changed list. Ugh.
Cannot track file renames. (Makes some refactoring painful.)
Cannot track file moves. (Makes some refactoring painful.)
Cannot track file deletes. (Makes some refactoring painful.)
Cannot track directory renames. (Makes some refactoring painful.)
Cannot track directory moves. (Makes some refactoring painful.)
Cannot track directory deletes. (Makes some refactoring painful.)
Introduction of new files is a slow and painful procedure, performed one file at a time. That is perhaps not a problem for the sluggish programmer that only creates a few new files every now and then, but for a productive programmer working on a new project, this makes version control a bottleneck.
It appears that if your adminstrator turns on enforcement of relating a Change Document to every change, you aren't supposed to change a file twice in response to a single Change Document. You can almost do it by "unrelating" the first revision from the Change Document before you check out. This is also a laborious file-at-a-time procedure.
Loses files once in a while. Make sure you keep a source backup outside Dimensions.

---

Cannot delete directories recursivly.-MatthiasPatzak?

---

Issues 5 to 11 and the delete recursive have been fixed in the release Dimensions 10 in 2006. Point 1 is an interresting topic, you can use various interfaces (desktop, web, windows explorer plugin, eclipse plugin, command line...), and your admin can create UI profile(s) to hide non necessary menus and features in order to simplify the GUI. Point 12 : this a parametrization choice done by the customer, must have a strong reason to do that.

- A serena consultant

PVCS Version Manager problems

Two or more files in the same project cannot have the same filename, even if they reside in different directories. How many files named makefile or build.xml do you have in your project? I haven't seen this issue at all, can you clarify? You mean if you forget to create projects within PVCS?
Unreliable concurrency control. I've personally seen teams trade files while simultaneously migrating from CVS to PVCS onto the same machine.
Clients need read-write access to the archive files to run the program.
A non-functioning client workstation can trash the entire project archive.

Hint: Ditch the VM GUI, script everything you possibly can with JakartaAnt or similar tool. Try to find a decent plug-in for your preferred IDE. After several months of fighting with it, my realization that the basic tool is OK, for what amounts to "a souped-up RCS", but the GUI makes everything way more confusing and complicated. --StevenNewton

---

This is absolutly right. PVCS Dimensions is really slow! And the GUI is a pain. The I-Net Client (Web-Client) is better, provides a better look-and-feel, but based on applets its slower than the PC Client. And the functionallity is really small. But the server itself has strong capabilities for supporting heavyweight configuration management. You can define lifecycles for everything. There have been two tips: Using an IDE-Plugin and script everything with ant. I just can support this. But then you are not using the strong server capabilites. So why should anyone use PVCS Dimensions? - MatthiasPatzak?

PVCS Advantages

It is fairly easy to do the minimum necessary. Most programmers can use it for a simple project where the only requirement is to hold an "incremental backup" of versions.
Some users find it no worse than "MS Visual Source Safe"
Multi-platform

An "advantage" demonstrates relative superiority to an alternative. Aside from being multi-platform, these "advantages" listed so far apply equally to most of the version control systems I've used, including SourceSafe! :-) The only one I know of that is not multi-platform is SourceSafe.

I believe PVCS is only multiplatform through the magic of NFS. (More things to buy, more things to administer.) Most other products (aside from SourceSafe of course) have a far wider range of platform support than PVCS.

PVCS is strictly filesystem-based. The client tools only know how to operate on files in a directory, and there is no client-server, or for that matter any sort of networking. At best PVCS is a souped-up RCS.

Gee, no offense, but if the best thing you can say about a product is "well, at least it's not worse than VisualSourceSafe", you might be better off not saying anything at all... --MikeSmith

''Another charming aspect of that "advantage" is that "some users" find it so. I hate SourceSafe, but I'll take SourceSafe over PVCS. Hell, I could probably track changes more quickly and painlessly with a manual process than with PVCS.

I have used both PVCS and Source Safe and will confirm item #3 above, "Dog Slow Retreival." PVCS may be acceptable if you allow your programmers to check out files for days at a time, but the slowness makes it difficult to convince people to do multiple check ins per day and only keep the files they are actively editing checked out.

Once again, I can't understand this objection. What kind of box were you running PVCS on that it took so long? I have never experienced this problem at any client I've been at. We're not talking about lightening fast host or server machines, either. -- MartySchrader

I use Dimensions every day on very fast machines. It's a dog. I'd speculate I spend about 10 percent of my day waiting for it to do simple things.

All that time lost to it, and it can't even track 6 of the 8 common mutations of a project. (See above. It can, however, track file creations and in-place edits. Bravo.)

My understanding of PVCS is that, by default, it keeps the original file as the baseline and then adds deltas to it. To recreate the current version, PVCS starts with the first checked in version and successively applies all changes. SourceSafe on the other hand, keeps the most current version of the file and only keeps deltas going back. SourceSafe always has the most current version available immediately. On a new check in, a delta file is created based on the current SourceSafe version and the new check in version. When getting or rolling back to an older version, however, SourceSafe will have to apply mulitple deltas based on how far back you want to go. This would lead credence to the slowness objection to PVCS.

If it is correct that PVCS recreates a file by repeatedly applying deltas to the original, which appears to be the case, consider the case where your PVCS client runs on a machine that accesses the repository as a network share. Not only does that mean that every bit of all the file's changes have to be accessed and applied, but that data all makes at least one network trip. Ouch.

That's the default. Silly default, but although it's been a couple of years since I worked with PVCS (VM), I think you used to be able to flip it the other way (store the most current version and deltas for going back).

This is all incorrect. I worked with the PVCS source itself, and it stores reverse-deltas. The current/tip copy of the file is stored in full and a delta to the immediately previous revision is stored, and so on. It gets slower to check-out as you go further *back* in the revision history.

I don't get all the PVCS hate. I've been using the VM-Inet client for about 4 years now. The java-based client was the slowest piece of crap I ever saw, and good riddance - but the VM-Inet applet (especially now for version 8) was fast and simple for developers to use. One really nice thing about PVCS is the promotion groups. I have not seen another source code control system that does anything like it - promotion groups make it really simple to make sure revisions have been QA'd - just don't permit developers to promote code, let the QA guys do that. The promotion groups also allow developers to checkin and checkout code all they like - code never gets marked for a build until it gets promoted, and the developer is in control of submission to that process. Promotion groups and event triggers make it pretty easy to mark a single piece of code with it's proper location in the development cycle.

I don't understand how promotion groups are different from a tag or a label on any other version control system. Can someone here talk about that a little bit?

I'm forced to use Dimensions 12 and it's so bad it should be shot and buried. And then nuked from orbit. I've stopped using the Eclipse plugin because it f*cked up too often and I had to refix changes that where already fixed. Checkout would not work and similar crap.

So I changed to the desktop client: Ever wanted to deliver changes in a folder hierarchy where only some files in several folders were modified? Good luck. Deliver finds out which files changes and which didn't. Obviously you want to ignore temporary build files. Well, that option does not exist. So you need to manually traverse every element and ignore unwanted ones. Luckily you can ignore subfolders, so you don't have to do that for every single file. Unfortunately that however is only available for ca. 10% of all folders.

What's the dumbf*ckery with the extension rules? Apparently it's supposed to help building. Unless someone fools with the extensions and you have some files that simply can't be checked in automatically. You need to create a new item manually and lie about the object type. Helpful this is not.

So you fixed several bugs/added new features to an object and checked in for every single one. Oh, something went wrong, so you want to check the differenced between checkins? Well, you can't. Unless you also promoted the object after every checkin. Which is such an utter failure for a version control this issue alone should mean hands off this POS.

AVOID AT ALL COSTS!

Related pages: AntHill (Build Management Server), SourceSafe, ExtremeVersionControlDiscussion, JakartaAnt, CruiseControl