Why PVCS sucks. I originally wrote this for work where I had to use PVCS, and I think it helped in my convincing them to try something else (which happened to be CVS, which isn’t perfect either, but is better and free).
- You can’t delete files.
- If a file is checked into the repository and then at a later stage is no
longer required then the file must either be deleted at all points in the
tree or will remain there forever. There is no way to say a file only exists
up to a certain point in time and at that point disappears.
Workaround: Define a LATEST tag and make this float with the tip of each file. Then to delete a file remove the LATEST tag from it. Requires all checkouts to be done from LATEST rather than just pulling normally.
- Checkouts are automatically locked.
- When a file is checked out it is locked. This means that it’s not possible
for a developer to check out a file, work on it and check it back in while
another developer also has the file checked out. This could, for example,
happen if someone is working on a new feature release and has checked out all
the files involved. A bug is discovered in the current release and someone
else checks out the code, fixes the bug and then finds they can’t check the
fixes back in.
Workaround: It’s possible to break locks so that the files could be checked in, but this requires the cooperation of a PVCS admin and also leads to the problem that the feature release checkout doesn’t have the bug fixes in it.
- There’s no way to update a checked out tree.
- If you check out a tree and someone else does some work on it and checks
something back in then there’s no way to pull the new changes into your
checked out tree. Either you pull the new file, removing any changes you’ve
made locally, or you ignore the new file and end up overwriting any changes
when you check your version back in.
Workaround: This normally wouldn’t come up, given that checking out a file locks it. However that leads to the problems above.
- It’s not easy to find changes in a local tree.
- If you check out a tree and do some development on it and then want to
review your changes against the repository you can’t, easily. This is
something revision control should do for you - it should make it really easy
to check what changes you’ve made to allow quick sanity checking and help
narrow down where problems are likely to have been introduced.
Workaround: It should be possible to do this by either checking out the whole tree again and doing a diff or using the PVCS command line tools to individually compare each file with its archive file. Neither is pretty though.
- There’s no local state.
- When you check out a PVCS tree there’s no local state pulled with it. There’s no easy way to tell what version you’ve actually pulled nor to come back to a tree after a period of time and be sure exactly what you’ve got.
- It’s not actually platform independent
- The PVCS repository appears to be tightly linked to where ever it was originally created. It’s not easy to move this and if created on a Windows UNC style share then it’s non portable to other platforms. In fact it’s not easy to access a PVCS repository from a variety of platforms, leading to the kludgy solution of having to check code out to an NT machine and then from there to the development environment.
- You can’t rename a file
- If you want to rename a file in a PVCS repository then it can only be done by removing the file from the repository, running the VCS cli tool on it and readding it. This is what the Merrant support site suggests and it renames the file at all points in time rather than just from the current point on the branch/mainline.
- No changesets
- When a file is checked in it exists on its own; it’s not possible to find all
the files that were updated as part of a particular checkin (say a bugfix
that touches several files; it’s not easy to pull out just the changes that
were part of that bugfix).
Workaround: It’s possible to work around this a bit if the same description is used for each file that’s checked in at the same time.
- Bad user interface
- There are several issues with the PVCS user interface. It’s extremely slow
for starters. Also checking in files can be non intuitive - it’s required to
explicitly state that unchanged files shouldn’t be checked in again, for
Workaround: None really except more use of the product to become familiar with it.