Re: PRCS question Josh MacDonald (jmacd@CS.Berkeley.EDU)
Tue, 18 Apr 2000 10:10:50 -0700

Quoting Jonathan S. Shapiro (shap@eros-os.org):
> > 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....
>
> Pardon me for a stupid question.
>
> How difficult would it be to implement a "prcs rename" command to automate
> this?

It would be pretty easy.

> > 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)....
>
> > 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.
>
> Agreed, and also agreed about the rest of your note.
>
> How difficult would it be to actually *implement* repository synchronization
> along the lines you describe?

As easy as socket(), bind(), listen(), accept(), and connect(). Security is the hard part. If you are willing to use ssh to establish secure connections then it should be pretty easy and rsync won't really buy you much. Each machine could just keep a log of files that it has and the last synchronization point for its peers logs. Since files aren't changing all you need is to figure out what new files there are and transfer them.

> Because DCMS stores everything as files, this can be accomplished easily
> with rsync(). There are only two tricky bits I can see:
>
> 1. Ensuring that a locally created branch (created while offline) gets a
> universally unique true name.

I would use a large random number as the "true name", though I like to use "identifier" instead of "name" in that case. People can name branches with local names from there (this fits with a realistic security architecture too).

> 2. Transferring control of a branch (i.e. control over the right to add a
> new revision) from one server to another (the problem is just getting a
> reliable atomic transfer protocol built. Oh. That's obvious. Never mind).

I'm not sure what you're thinking about with transferring branches. I would instead think that you want to create a local branch, descendent from the common one you said to transfer, and use it for extended remote development. You return to the common branch with a merge/checkin.

> Is there some mechanism of comparable simplicity that would allow two
> related rsync repositories to be synchronized offline? In the short term,
> I'll carry the whole damn repository on my portable if it lets me work on
> the road and I can get it decently well compressed.

Yes, I think rsync could be used.

-josh