# From: Michael Cook <cook at sightpath.com> [...]

Maybe considered a hack, you may easily change name of a file simply by renaming it in the repository (mv This.h that.h). This will automatically force a removal of the old file in the user workspace (since it is listed in CVS/Entries but does not exist on the server anymore) and a checkout of the renamed file next time the user performs an 'update'. Ofcourse you should be careful! You even perform backups periodically, do you not?

True! This is a fact with CVS. CVS does not keep metadata about files and actions on files. You should always tag the source branch prior to merging into another branch since you later may not re-merge changes prior to that tag to the destination branch. Anyhow you could also tag the destination branch after having committed the changes from the merge. By selecting informational tag-names you _could_ track which merges were done and from what other branch etc. This way YOU are doing the metadata collection. In my opinion this is a good reason for using Perforce instead ;-)

What I have not seen in this discussion is reasoning about the ability to handle component based development. We are developing a client-server solution (and have been since '92 or so) with server parts on a lot of Unixes (Unices :) and Win NT sharing almost the whole code base. At the same time we share several libraries among these server platforms as well as a lot of client platforms such as those Unixes, Win 9*, Win NT and MacOS. The main issue here is that we must partition the CVS repository into one module/tree for each platform-specific server and client configuration while keeping platform independent code aside. This calls for extra measures when setting up the user workspace. We do this by adding a perl script at the proper location in each platform specific module/tree and doing a two-step checkout:

1. First we perform a target checkout (cvs -d <stuff> checkout client-win)

2. followed by an invocation of the script: (cd client-win\src; perl <checkout-script>) which adds the platform independent libraries etc to the client workspace.

Together with the script we also keep a modules.lst file that contains mappings from the repository into the workspace: libcli share/libcli libtiff share/libtiff libtcl share/libtcl <workspace location> <repository location>

My point is that this is done inherently when setting up the client workspace in Perforce! There you pick modules from the repository and designate client workspace directories for keeping them. If you are targeting several hardware or OS platforms and are sharing code among them you will have to deal with this explicitly in CVS one way or another!

Another extremely anoying feature of CVS is the lack of commit-information. As soon as the commit is done, no trace of its passing exist anywhere in the system _except_ in logfiles (which calls for a hard time at developing scripts that utilize this information, if it is possible at all). You _could_ try to determine which files where part of a commit by indexing all files in the repository and studying their timestamps, but hey! this is done by Perforce! Why is this of any importance? Consider having made function increments together with bugfixes on the main trunk after last release. If a critical bug turns up in the released software you may find that this was already fixed on the main trunk. Could you extract these changes and reapply them on a branch situated on the releaselocation? Happy hunting for clues as to which files were involved in that particular fix. If several fixes are needed you could actually be forced to produce a new release ahead of time probably with some new functionality stripped away since it ends up being harder to reapply the fixes on the patch branch. And even if you do, maybe fixing some more bugs that was found during tests, would you really dare to merge this patch-branch into the main trunk? Conflicts is the name of that game.