kerberos and cvs

[Charles Wilson]

Max Bowsher wrote:

> Chuck, are you sure this is a good idea? cvsnt has recently dropped any
> pretence of mainining syncronization with cvshome. 

I know.  I considered that a *good* thing (with one caveat) -- if any 
fixes go into the cvshome tree, they'll grab 'em -- but they won't be 
held back, either.  Which means they can update to new autotools (unlike 
cvshome) etc etc.

The "wire" protocol is the same; cvsnt will always be able to talk to a 
cvshome :pserver: on another machine, or to an :ext: server on another 
machine.   And vice versa.

[caveat] The big question is, how has the on-disk storage format 
changed?  If I have a pre-existing repository that I've been accessing 
via :local:, can I simply "drop in" cvsnt and go?  Ditto working 
directories?   Can I then switch BACK to regular cvs (or does cvsnt do a 
one-time "upgrade"?)

I don't know the answer to those questions, but I'll find out 
eventually.  Backwards compatibility is THE foremost goal.

> Or, even, is there any
> reason not to have *both* cvs and cvsnt in the Cygwin distribution?

No, not really -- except that I don't want to maintain both.  Plus, if 
there IS some conflict in the on-disk formats, can you imagine the FAQs?

> I've been playing with cvs-1.11.5 and sanity.sh. There are no regressions
> when run with ntsec on.

That's an improvement.  Were you building with, or without, the gdbm 
patches?  binary or text mounts for repository X binary or text mounts 
for working dir?

> Do you have any intention to release a cvs-1.11.5 package? 

Well, it depends on how hard this cvsnt project is.  given the 
text/binary issues that were reported when I trial'ed 1.11.2, I'm leery 
of doing an update without significant reqression tests on "real world" 
repositories.  But I don't have the time for that.

Since 1.11.0 ain't broken (in client mode -- the security fixes were in 
server mode and we don't have a working server) -- I've left it alone. 
I know that means we don't have the new rlog command, but...

> If not, would you
> prefer I made one and offered it to you for review, or that I ITP'ed it on
> my own?

Are you offering to take over the package? If so, I'd be cool with 
that(*).  Or, if you simply wanted to up-port the changes from my 
aborted 1.11.2 package (**) and do a one-time-only, help-Chuck release 
of 1.11.5 that'd be fine, too.

(*) But, the gdbm patches are a problem.  There are three solutions, as 
I see it:
   1) keep using them
   2) verify that one may simply delete CVSROOT/modules.db and 
CVSROOT/valtags.db with NO ill effects (since all the same data for 
modules.db is in modules, and val-tags.db is just a compressed lookup 
table that will be regenerated on-the-fly. I think <g>).
   2a) If so, then we can build cvs without gdbm.
   2b) If not, create a dumper program to read the gdbm data from the 
.db file and dump to a cvshome-compatible flatfile.  Hacking the 
appropriate code together to do this is left as an exercise for the 
interested reader.

(**) These changes were of four different sorts:
   a) __CYGWIN32__ -> __CYGWIN__
   b) configury changes to support gdbm (acinclude.m4, configure.in, 
Makefile.am's, etc)
   c) source code changes for the gdbm stuff (use macros DBM_FETCH 
instead of dbm_fetch; define DBM_FETCH to point to gdbm, ndbm, or 
cvs-specific database routines)
   d) autoreconf

Oh, and a few open() mode changes.

See http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/cvs/
My 'make check' results are there, too.

--Chuck