PING?

Charles Wilson wrote:

> I maintain the cygwin distribution's "cvs" package.  Attached is a 
> tarball containing the changes currently used in our version, against 
> cvs's ccvs repository.  These changes should be non-disruptive to other 
> platforms, although you may decide to move the AC_ARG_WITH([gdbm], ...) 
> outside the 'if cygwin' block; it could be useful on other platforms.
> 
> A full changelog is appended.
> 
> The tarball contains four files:
> 
> 1) cygwin-ccvs-primary.patch
> changes to original source files -- but not autotool-generated files
> 
> 2) cygwin-ccvs-secondary.patch
> changes to autotool-generated files that are caused by the modifications 
> in -primary.  I was using automake-1.6.1 and autoconf-2.53a.
> 
> 3) gdbm_wrap.c
> 4) gdbm_wrap.h
> Two new files that should go into the src/ subdirectory.
> 
> These gdbm_ files were necessary because on cygwin, if the user hosts a 
> repository on a FAT drive (FAT does not support hardlinks, NTFS does), 
> then she is limited to flat-file databases (myndbm).  This is because 
> cygwin's ndbm support is provided by gdbm -- and gdbm's ndbm emulation 
> relies on hardlinking foo.pag and foo.dir.  Our solution was to use 
> 'gdbm_open', which needs only a single (.db) file, instead of libgdbm's 
> 'dbm_open' (which would trigger the ndbm emulation mode and hardlink 
> failure).  However, the remaining dbm_ calls can stay mapped to the ones 
> provided by libgdbm.  Hence, we "wrap" dbm_open, but thunk dbm_<not open>.
> 
> Other changes: autoconfigury to support the --with-gdbm argument, 
> cosmetic __CYGWIN32__ to __CYGWIN__ changes.
> 
> We've been using the basics of this scheme for over 18 months now, 
> against cvs-1.11.0, and it works pretty well.
> 
> I recently ported our changes up to cvs-1.11.2.  Many of the changes 
> that I found were necessary to 1.11.2 I later discovered you had already 
> done in ccvs-HEAD.  Oh well.  So, my new port of cvs-1.11.2 -- even 
> though it uses the same gdbm stuff described above which has been a part 
> of the cygwin-1.11.0 port for 18 moths -- has itself been less 
> thoroughly tested than the well-seasoned 1.11.0 version.  However, it 
> DOES pass almost all of the sanity checks (cygwin-special-cvs-1.11.2 
> performs better than cygwin-special-cvs-1.11.0, actually).  There are 
> only five :local: failures:
>   local, join-readonly-conflict (subtest join-readonly-conflict-10)
>   local, modules (subtest modules-148a0)
>   local, modules6 (subtest modules6-1)
>   local, binfiles3 (subtest binfiles3-11)
>     expected.  'admin -o' is disabled on windows/cygwin
>   local, errmsg1 (subtest 168)
> and five remote (:fork:) failures
>   remote, modules (subtest modules-148a0)
>   remote, modules6 (subtest modules6-1)
>   remote, binfiles3 (subtest binfiles3-11)
>     again, expected.  'admin -o' is disabled on windows/cygwin
>   remote, errmsg1 (subtest 168)
>   remote, crerepos
>     when testing in remote mode, crerepos uses :ext: instead of
>     :fork:.  Therefore, I expect to fail, because I didn't have
>     rshd running.
> For the cygwin platform, that's really good.
> 
> Extremely pleased with my work, I rushed over here to give you guys my 
> patches -- and discovered that a lot has changed in ccvs since April 17 
> when 1.11.2 was released.  So, I RE-updated the cygwin changes to apply 
> cleanly to ccvs-HEAD.  It builds fine -- on cygwin -- and I expect 
> similar test results as above.  But that takes hours and it hasn't 
> finished yet.
> 
> Please let me know if there is anything further I need to do, to help 
> you guys incorporate these changes.  (sign a copyright assignment, etc). 
>  Oh, and pls CC: me on replies as I am not subscribed to this list.
> 
> Thanks,
> Charles Wilson
> 
> 
> 2002-05-20  Charles Wilson  <[EMAIL PROTECTED]>
> 
>     * acinclude.m4: define macros for --enable-encryption,
>     --enable-server, and --enable-client, using code from
>     configure.in.  Also, define a new macro for --with-gdbm,
>     used in the cygwin port.
>     * configure.in: Use the four macros defined above.  Also,
>     use AC_DEFUN() instead of define() for WITH_KRB4. Replace
>     refenences to cygwin32 with cygwin.
>     * src/Makefile.am: add gdbm_wrap.c and gdbm_wrap.h to the
>     sources list.
>     * src/cvs.h: Make accomodations for --with-gdbm; use
>     gdbm_wrap.h instead of myndbm.h or ndbm.h when appropriate.  Use
>     CAPITALIZED names for dbm_ functions, to avoid conflict with any
>     pre-existing versions.
>     * src/mkmodules.c: use DBM_CLOSE instead of dbm_close, etc.
>     When --with-gdbm, database files end in .db, not .pag.
>     * src/modules.c: use DBM_CLOSE instead of dbm_close, etc.
>     * src/tag.c: use DBM_CLOSE instead of dbm_close, etc.
>     * src/myndbm.h: instead of REdefining dbm_open to mydbm_open,
>     define DBM_OPEN as mydbm_open, etc.
>     * src/gdbm_wrap.c: new file. Implements wrap_gdbm_open,
>     which calls libgdbm's 'gdbm_open' after building the correct
>     filename.  Does NOT use libgdbm's ndbm emulation layer.
>     * src/gdbm_wrap.h: define DBM_OPEN as wrap_gdbm_open, but
>     define other DBM_*() to dbm_* so that libgdbm's versions
>     are used directly.
>     * src/options.h: make accomoations for --with-gdbm.
>     * lib/system.h: change __CYGWIN32__ to __CYGWIN__
>     * src/rcs.c: change __CYGWIN32__ to __CYGWIN__
>     * windows-NT/README: change CYGWIN32 to CYGWIN.
>     * aclocal.m4: regenerate
>     * config.h.in: regenerate
>     * configure: regenerate
>     * src/Makefile.in: regenerate



_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs

Reply via email to