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