Nate Williams wrote: > > > The value specified in CVSROOTCACHE is the local path to the cache > > repository. All the check-outs, updates, diffs etc. will be obtained > > from there. All the check-ins, tagging etc. will go into the master > > repository specified by CVSROOT. Naturally, to see these changes > > in the cache repository, it needs to be updated by some outside > > means such as CVSup or CTM. > > So, the cache doesn't automagically update itself when commits are done? > This is less useful, since often-times after a commit has been done the > user is still working in the same general area, so a 'cvs update' would > now give the user older files since the read-only cache is not > up-to-date, thus making it a requirement that everytime you make a > commit, you also sychronize the cache.
That's the plan for the next stage, provided that the first stage goes well. I'm yet to play with CVSup and see if it can be integrated there (as with system()) easily without making a lot of changes to CVS itself. Otherwise I'm aftarid it's going to be a large amount of work to duplicate this functionality :-( Yet another idea is to be able to make "local commits" with committing them to the central remote repository later. Now I have to use RCS locally for the temporary in-delevopment versions of file. Would be nice to have a kind of a local branch which can be later committed as a whole - in one commit per file, or by duplicating all the intermediate versions with their messages. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message