2002-04-29 prcsstatus 1 prcsstatus What's in my tree? prcsstatus -w -P -w append unknown files to .ignore in each directory -P don't consider project control files prcsstatus walks from the current directory upwards stopping when it finds one or more files which end in .prj (PRCS project control files). This directory is known as the project root. For each of the .prj files in the project root, it gathers a list of the files in that project, warning if a file is present in more than one project. It then gets PRCS to generate 3 sets of diffs: working vs common, selected vs common, and selected vs working. It stashes the results of these diffs for later use. prcsstatus then walks down the directory tree from the point where it was initially started, printing a one-line summary of the state each interesting file is in. A file is interesting if it has been changed somewhere, either in your tree or in the PRCS repository. The possible states a file might be in are as follows: ? : unknown A file is unknown if it is not mentioned in any project in the project root. These files might be newly create source files which should be prcs populate-ed or might simply be junk files. You can list files to be ignored by listing them in a .ignore file in the same directory. These .ignore files can be automatically generated by invoking prcsstatus with the -w flag; this is useful immediately after the first compile when all the generated files have been created but no changes have yet been made. M : modified A file is modified if you've edited the copy locally, and no-one else has checked a newer version into the repository. U : updated version in repository A file needs updating if someone has checked in a new version to the repository, and you haven't edited your copy. A straightforward prcs merge should fix this. 3 : 3-way conflict A file has a 3-way conflict if it has been edited locally, and the local copy is no longer the latest, and the originally checked out version is not the latest. This is quite a complex condition, and it can arise in one of three ways: same as M: you've done a merge, then subsequently edited the file; or same as U: you've done a merge, then someone else checked in; or real conflict: you've done a merge, edited the file, then someone else has checked in. Unfortunately, prcsstatus is unable to tell these three cases apart: they all look alike. This is the major weakness of prcsstatus. The real problem is that PRCS makes it hard to to tell the result of a merge apart from your own edits: both look like the file has been edited locally. O : only in ... One of the 3 diffs said the file only existed in one of the versions. This could be because the file has been deleted in the repository, or because this is a new file that has been prcs populate-ed but not yet committed. Again, this is an area in which prcsstatus could be improved to detect which of these distinct scenarios is actually the case. I wrote the prcsstatus tool because I'd used cvs before and liked the way I could type cvs -n update to get a concise listing of what I'd changed in my working tree. Then we started using PRCS at work, and I found it impossible to work out what was in my tree. Furthermore, the way we use PRCS is to have multiple projects checked out on top of each other, such that each file in the working tree is owned by one PRCS project. Dealing with this was the final straw that broke the camel's back: I needed something to tell me the status of each file in my tree, and which PRCS project was responsible for it. Thus was born prcsstatus. Please mail bug reports, etc, to Austin Donnelly Austin_Donnelly@yahoo.co.uk. Patches to fix bugs or add features most welcome! Austin Donnelly Austin_Donnelly@yahoo.co.uk This manual page was translated to DocBook by Rafael Laboissiere rafael@debian.org.