Date: Mon, 12 Jan 2004 12:35:59 -0500 From: Chris BeHanna <chris@behanna.org> To: hackers@freebsd.org Subject: Re: Where is FreeBSD going? Message-ID: <200401121235.59788.chris@behanna.org> In-Reply-To: <20040108180552.GA17378@opiate.soulwax.net> References: <Pine.NEB.3.96L.1040107151556.6025A-100000@fledge.watson.org> <1073582974.37229.8.camel@herring.nlsystems.com> <20040108180552.GA17378@opiate.soulwax.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 08 January 2004 13:05, Munish Chopra wrote:
> On 2004-01-08 17:29 +0000, Doug Rabson wrote:
>
> [...]
>
> > The three main showstoppers for moving FreeBSD to subversion would be:
> >
> > 1. A replacement for cvsup. Probably quite doable using svnadmin
> > dump and load.
> > 2. Support for $FreeBSD$ - user-specified keywords are not supported
> > and won't be until after svn-1.0 by the looks of things.
> > 3. Converting the repository. This is a tricky one - I tried the
> > current version of the migration scripts and they barfed and died
> > pretty quickly. Still, I'm pretty sure that the svn developers
> > are planning to fix most of those problems. From mailing-list
> > archives, it appears that they are using our cvs tree as test
> > material for the migration scripts.
>
> [...cvs2svn.py scheduled for 1.0...]
What about "arch"? I have it installed, but $realjob has
prevented me from looking at it.
And, unless I misunderstand, Perforce is available for free for
non-profits, and the client is a free download. Other than a desire
to be "pure" and use open source exclusively, what objection is there
to Perforce? (And even considering that desire, Perforce is built
upon open source: RCS and BDB, if I understand correctly).
Speaking as a former CVS repo-meister (for a company that
evaporated out from under me), Perforce really is a better mousetrap.
No more, "I updated in the middle of a commit" problem, because
commits are transactional. No more "Oh, god, this merge sucks",
because Perforce keeps track of what was merged when, and where. The
latest versions rather painlessly support cross-branch merges, too
(i.e., pulling changes from one branch to another without having to
first push up to and pull down from a common ancestor). Triggers can
be written to prevent inadvertent DoSes
(p4 integ -I //depot/branch1/... //depot/branch2/...) and to do
submit-time checks.
Risks are more easily mitigated with branches, and pulling/pushing
of selected changes is MUCH easier (no more need to generate and apply
patches by hand). Generating weird-elmo hybrid mappings of the tree
is also a snap, and the repo itself doesn't bloat as badly because P4
uses its database to keep track of where histories go, rather than
actually physically copy a file to move it in the repo.
CVS:
cp /CVSROOT/foo/bar /CVSROOT/foo/baz
cvs delete foo/bar
cvs commit
(but bar,v lives forever, if you want to keep the change
history and/or if you ever want to check out an old tagged
revision of the tree)
Perforce:
p4 integ -t foo/bar foo/baz
p4 delete foo/bar
p4 submit
(foo/baz doesn't actually physically exist. P4 keeps a DB
record that foo/baz points to foo/bar, and this operation is
only visible in the branch in which it was done, until that
branch is pushed up to its parent)
With Perforce, no repo-meister intervention is needed.
Add in the ability to use local proxies to cache
frequently-fetched files and revisions, and you have a winner,
IMHO.
I'm starting to sound like a spokesman. I'm not--just a *very*
satisfied user.
--
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
chris@bogus.behanna.org
Turning coffee into software since 1990.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401121235.59788.chris>