bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[3rd attempt] patches for cvs on cygwin


From: Charles Wilson
Subject: [3rd attempt] patches for cvs on cygwin
Date: Thu, 13 Jun 2002 18:44:22 -0400
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2

Is anybody listening?  Is this the correct list for patches?

these patches were first posted on May 20:
http://mail.gnu.org/pipermail/bug-cvs/2002-May/008191.html

Resent two weeks later on Jun 3:
http://mail.gnu.org/pipermail/bug-cvs/2002-June/008436.htm

No response in either case.

---------------------------------------------------------------------

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.

<<<< ED. note:  it did finish, with results like those above >>>>

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  <address@hidden>

    * 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

Attachment: cygwin-cvs-patch.tar.gz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]