Date: Tue, 11 Sep 2001 11:44:26 -0700 From: "Mark D. Anderson" <mda@discerning.com> To: <freebsd-hackers@freebsd.org> Subject: Re: local changes to CVS tree Message-ID: <0d7201c13af1$dbcf74a0$6501a8c0@mdaxke> References: <0ab401c138e7$f0ff2b60$6501a8c0@mdaxke> <01090920122401.00426@antiproton.ChrisBowman.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I use perforce at work, and I think it is a really great tool. That said it > does have a few drawbacks. For one my experience is that perforce is really > only suitable for use in a situation where you are well connected to the > server. You can check out a set of files and work with them, but if you want > to do things like diff two repo versions you have to be connected to the > server at the time. In contrast you can keep a local copy of the cvs repo > and do just about everything locally, I haven't found this capability with > perforce. Also you can very efficiently fetch the entire cvs repo with cvsup > which is really a marvelous tool. I am not aware of a method to do this with > perforce. Finally just about my favorite cvs feature is cvs annotate which I > have not yet found a way to do under perforce. Do you know of a way to do > this? in any scenario, compatibility with existing cvs practices would have to be largely preserved. i was imagining a perforce repository for committers, and a readonly cvs server kept up to date by triggers, to support existing (readonly) practices. this would allow for advanced branching/merging against that perforce repository, without the limitations of cvs. an alternative would be to reverse the relationship, keeping cvs as the master, and constructing perforce slave snapshots. according to kris kennaway, that is already being done for some longer freebsd projects. i don't see how that directly solves the stable vs. current problem, however. "cvs annotate" can either be done against a slave cvs, or a similar report could be constructed against perforce. it is really just a report, after all. as for the other areas you mention, perforce does not directly support repository-to-repository replication, nor disconnected operations. if replicas are required, rsync (which is not atomic at the database level), or journal playback could be used, though both would require work. i do not know if perforce supports branching against a "remote depot"; i suspect something like that would accomplish the same goal. but maybe not. the whole question of distributed repositories is kind of a hot button in the CM world, because historically that feature, which clearcase has, was pushed as a solution in circumstances where it was not appropriate, and the simple client-server model works fine (for example, two corporate offices of the same company, both in the U.S.). > Finally, what about other version systems does any body have any comments or > experience with Ageis, bitkeeper or subversion? and what about that thing > the Evind was writing? i don't know anything about Evind; here is a brief summary of some of the other alternatives. all IMHO of course. Aegis (GPL, http://www.canb.auug.org.au/~millerp/aegis/aegis.html ) the pro and the con of aegis is that it enforces a whole change lifecycle, ensuring that submitted changes still compile and pass tests. it seems unlikely that all freebsd committers would care for this approach. If stripped of those abilities, leaving just a source control system, i doubt it is worth it, though i'm sure aegis advocates would disagree. Aegis does have excellent support for name operations (rename/delete/mkdir), one of many things cvs is horrible at. bitkeeper (bitkeeper license, http://www.bitkeeper.com ) bitkeeper was apparently inspired in part by a desire by larry mcvoy to supply linus and linux with a better solution than their current one, although to date there is no sign of it being adopted; judging from the email archive this seems mostly due to it having a free-only-for-free-projects license, though i wonder too if linus ever thought he needed an alternative to begin with. it takes the approach that every workspace is a repository; there is no distinction between a workspace sync and a repository sync; they are the same thing. furthermore, repositories can be placed in a hierarchy. this capability (insofar as i understand it) is used not only for disconnected operations and distributed repositories, but also for what other systems would consider "branches" or "lines of development". if you really feel you need such a distributed model (i.e. distributed repos, not just distributed clients), it is probably worth a look. bitkeeper has its own bitkeeper license. for non open source projects, it allegedly has close-to-clearcase level pricing. subversion (apache/bsd, http://subversion.tigris.org/ ) probably the most active effort for an open source replacement for CVS. as of a week ago it just hits its "milestone 3", of being self-hosting (it was previously using CVS to keep its own sources). it is still being actively worked on; now is probably not a good time to adopt it. while it intends to supplant CVS, it is inclear to me whether it will support a CVSup equivalent. PRCS (GPL, http://prcs.sourceforge.net/ ) Josh MacDonald's labor of love. because of his background, has a very strong backend storage mechanism (xdelta). appears not to have distributed repositories. as with aegis, good about name operations. If anyone has a more detailed review of these alternatives, discussing the specifics of branching support, namespace changes, repository replication, view definition, and so on, i'd be interested to see it. But usually discussions of CM tools are about as informative as discussions of text editors.... -mda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0d7201c13af1$dbcf74a0$6501a8c0>