Re: PRCS question Josh MacDonald (jmacd@CS.Berkeley.EDU)
Mon, 17 Apr 2000 16:11:20 -0700

Quoting Jonathan S. Shapiro (
> Since Josh is on our list, a few questions about PRCS:
> 1. Does it handle renames? I recall a way to hack the file that described
> the state of the arena to handle this. If this is doable but PRCS does not
> handle renames directly, surely it would not be difficult to add rename
> support?

It does have rename support. You have to perform the rename yourself in the file system and then edit the project file to reflect the change. Merge and diff commands respect these changes by using the file's family, not its name, to associate versions. There is an extra phase during merge that asks the user what should be done about naming conflicts.

> 2. How hard would it be to do a stupid repository synch mechanism? I
> understand that in the end the goal is to do everything with minimized bit
> transfer, but right now we all need something that works more than we need
> something that works well. How hard would it be to implement nested
> repositories in a naive way, and what are your (Josh's) thoughts on how one
> might best go about it?

I'm not sure what you mean. One of the nice properties of a version control system is that once a version instance is recorded in the repository it becomes an immutable member of the set of all versions. The set only grows. So the simple answer to your question is that you can synchronize repositories by exchanging versions until both peers have the complete set of versions.

There are two types of file in the repository: those that are members of a sequence (e.g., branch records), and those that belong to unordered sets (e.g., versions referenced by branch records). Each sequence requires a centralized entity to serialize access to the branch. You've already discussed signing of these branch records. This effectively separates branch access from repository synchronization. I wouldn't describe this type of repository as nested, I was say it is decentralized. Synchronization still takes place by exchanging versions until both peers have a complete set, only the complete set depends on the branches you are interested in synchronizing.