This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]