compiling cvsup broken on -current
Simon 'corecode' Schubert
corecode at fs.ei.tum.de
Tue Nov 1 12:42:20 PST 2005
Hey,
as the release is coming close we need to find a solution for the cvsup
problem:
After our ABI changes in -DEVEL (to be -RELEASE) you can't compile
cvsup from ports/pkgsrc anymore because ezm3 has a wrong opinion about
the system structures.
The biggest problem here is that ezm3 can't use C headers to build its
support library and thus you always have to manually (!) patch ezm3 to
get it to use new system structures. This is very error prone and
quite complicated, as you need several steps to produce a correct
working bootstrap kit. (Plus nobody I know who speaks m3 really well)
One way is to use the FreeBSD-4 or DragonFly-1.2 packages with
COMPAT_DF12 on the new systems, but this is at least slightly
embarrassing.
An alternative would be using cvsync, like I think OpenBSD and NetBSD
are using as part of their infrastructure. But cvsync has other
issues: 1. I can only operate in RCS mode, it doesn't offer checkout
mode. 2. under certain conditions it puts entries in RCS files in the
wrong order so that cvs annotate can't work on them anymore (cvs
ci/co/up/log works, tho). I have a temptative fix for this but the
maintainer would like to have it fixed in a different way.
Then there is the csup project: Yet csup is just the client, for the
server you still need a working ezm3. Furthermore csup can only
operate in checkout mode and not in RCS mode. I don't have any
experience on how mature this is.
To distribute the repos, we could as well use rsync. While some people
say that it is not suited for large trees, I can't find this of an
issue with the DragonFly CVS repository. I can do an empty sync
(everything updated) with rsync in <7 seconds, that's <3.5 secons for
each tree run (if cached, of course). It isn't specialized for syncing
CVS files, but it does a good job.
To get the checkouts one could use plain anoncvs or cvs+ssh or rsync
checked out trees from the server (latter I don't like).
Note that I am running all (except for the checked out tree rsync) on
my mirror and don't have any problems except those mentioned.
We need to come to a sensitive decision in a short time so that mirrors
can accomodate with that before the -release rush starts.
Maybe just polishing one of the cvsync or csup projects would do fine
for us, maybe we would like to develop something completely new. In
any case, this won't affect the next release, but the decision on what
we are doing now shouldn't be orthogonal to that what we will be doing
lateron.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Attachment:
PGP.sig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00000.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20051101/f3c9fef2/attachment-0020.obj>
More information about the Users
mailing list