This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: kerberos and cvs
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