Date: Wed, 09 Jul 1997 16:56:04 -0700 From: Josh MacDonald <jmacd@CS.Berkeley.EDU> To: Nate Williams <nate@mt.sri.com> Cc: current@freebsd.org Subject: PRCS (was Re: CVS Branches hits again!) Message-ID: <199707092356.QAA11916@paris.CS.Berkeley.EDU> In-Reply-To: Your message of "Wed, 09 Jul 1997 16:06:54 MDT." <199707092206.QAA28979@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> [ PRCS ] > > > Some things it yet lacks are: > > > > 1) a client server environment > > Becoming more important as FreeBSD developers are now starting to use > it. This is currently my first priority. I've kept pretty quiet and not pushed PRCS in too many places because of this, but spoke up now because I figure PRCS would be no worse than CVS since people seem to be using CVSup. I have a pretty cool design for the client-server archetecture which solves one of the problems I've noticed from users of CVS on these lists: people want to mirror a repository with their own modifications (branches, local changes, etc.) while at the same time participating in the global development effort and being able to synchronize repositories. My solution is to incorporate mirroring capabilities similar to those of CVSup into PRCS and allow branches to be marked LOCAL. Local branches don't participate in global repository synchronization. Towards this goal, as I hinted in previous mail, I've got a design for a new RCS-like version-file library using a delta algorithm of my design to replace the somewhat flawed usage of diff(1) (or any insert/delete delta) in the RCS file (if this doesn't make sense and you're interested, email me). I figured it would be easier to construct a new delta program and solve some outstanding problems than to write yet another RCS file manipulation library to deal with an old, flawed format. (The delta algorithm is implemented, the version-file library is only designed). How many of you are using CVS's client-server capabilities directly? Is it enabled/encouraged on freebsd.org? > > 2) recursive module semantics > > Pretty much unused. What I mean here, is that CVS basically versions a tree of directories and lets you name a module after various locations in the tree. PRCS would rather you treat each CVS-module as a seperate project. This leaves some coordination between modules undealt with. I suspect this is largely not a big deal, as long as a few conventions are maintained so that release engineers don't go crazy. > > 3) developer notification services (mailing-list notification, for > > example) and other command hooks (I want programmable extensions > > for the purpose of implementing these and the stuff below). > > This is pretty much critical for FreeBSD, as well as many of the other > projects I use CVS for. Having a 'log' trail is good, as well as > sending message to the developers. Right, I knew this would be a catch. Were this the only catch, I would be happy to add in everything you need. > > Some things that it lacks and should be left to policy: > > 1) file locking such as CVS's watch and edit (are you, the freebsd > > developers, using it?) > > Not really important to me. > > > 2) checkout histories such as CVS's history command (which I beleive > > you have disabled) > > Not so important for me or the projects I've used it on. > > > Some advantages: > > 1) Better branching model. > > Can you expound on this a bit? Mostly it comes as a result of atomic checkins. There is a big reduction in the complexity by avoiding such issues as vendor branches, tags, sticky tags, magic version numbers, and all that. Since each version is labeled with a unique MAJOR.MINOR pair and RCS-like tags are not used to label individual files, you have a much stronger notion of how your project branches and the events that occur on each branch. Admittedly, you can do the same stuff in CVS and in PRCS, but I argue that with PRCS it is easier to know what you're doing, what to do, and what you've done. CVS branches files for you and asks you to do all the branch management with tags. PRCS branches projects for you and lets you forget about individual file branching (it resembles Perforce in this way, though we both have different terms for what's going on). > > 2) Atomic operations (this is this single most losing feature of CVS, > > IMHO). > > No kidding. > > > 5) control over symbolic links and keyword replacement, including custom > > keywords. > > CVS has this control, though it isn't well documented. > > Nate I also sort of left out the things like the ability to rename, delete, and later readd files and directories. There is no such thing as -P, because PRCS knows about project versions, not individual collections of files. It knows that some directory didn't exist in a certain version and doesn't check it out, simple as that (it also knows how to maintain empty directories). There is no attic. There is no section in the manual describing three different equally bad ways of renaming a file. Nowhere in the PRCS documentation is the structure of the repository defined, it is completely unspecified to prevent people from making direct respository modifications. I neglected to give URLs for people to check it out. Documentation, links, a tutorial on advanced uses of merge (for the version-control impaired) are at: http://www.xcf.berkeley.edu/~jmacd/prcs.html and distributions are available directly from: ftp://ftp.xcf.berkeley.edu/pub/prcs The current latest version there is 1.2.0b8 but as I said, I expect to release 1.2 on public forums in the coming week. -josh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707092356.QAA11916>