prcsstatus(1)
NAME
prcsstatus - What's in my tree?
SYNOPSIS
prcsstatus [ -w ] [ -P ]
OPTIONS
-w append unknown files to .ignore in each directory
-P don't consider project control files
DESCRIPTION
- prcsstatus walks from the current directory upwards stop
- ping 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 local
- ly, and no-one else has checked a newer version into the reposi
- tory.
- 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 elsechecked in; or
- real conflict:
you've done a merge, edited the file, thensomeone 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.
HISTORICAL NOTE
- I wrote the prcsstatus tool because I'd used cvs
- <URL:http://www.sourcegear.com/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 <URL:http://prcs.source
- forge.net/> 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 prc
- sstatus.
BUG REPORTS
- Please mail bug reports, etc, to Austin Donnelly
- <Austin_Donnelly@yahoo.co.uk>. Patches to fix bugs or add fea
- tures most welcome!
AUTHORS
Austin Donnelly <Austin_Donnelly@yahoo.co.uk>
- This manual page was translated to DocBook by Rafael
- Laboissiere <rafael@debian.org>.
11 May 2006