* cvs-1.11.2 test release
@ 2002-05-19 22:14 Charles Wilson
2002-05-20 22:37 ` Charles Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Charles Wilson @ 2002-05-19 22:14 UTC (permalink / raw)
To: cygwin
I've made a test release of cvs-1.11.2-1 available on my website.
This version isn't even ready for 'normal' testing use; do NOT use
it for your day-to-day cvs'ing. ONLY use it if you actively want
to help squash bugs. (however, it does pass more of the selftest suite
than the existing 1.11.0-1 release -- but I give NO WARRANTY, EXPRESS OR
IMPLIED, that 1.11.2-1 will work in day-to-day use or not).
Using setup, you need to add this URL to your mirror list:
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
Then, you must explicitly click thru the version numbers for the
cvs package until 1.11.2-1 shows up.
The purpose of this test release is NOT to fix existing bugs, but instead to
1) update to current sources (1.11.2)
2) migrate to "script-based" building
That way, other folks will have an easier time building cvs ( and thus,
helping and providing patches.) I'm reminded of the post a few days ago
where somebody "fixed" cvs's build -- by deliberately removing MY_NDBM
which serves only to BREAK cvs on FAT...sigh). Arguably, that was my
fault -- the earlier -src package was not trivial to build, and required
manual intervention.
Also, by using the most current official version of cvs, we will be
working with the best available code instead of two-year-out-of-date code.
But, I have NOT tried to actually FIX any extant issues. That's up to
you guys. Patches, patches, patches...
rambling side note: we don't want to link against automode.o -- read
EVERYTHING in text mode (e.g. strip out \r's), and write EVERYTHING in
binary mode (e.g. don't put the \r's back). Effectively, this will
eventually dos2unix convert all the accessed files. We don't want to do
that because it wouldn't be appropriate for all files -- what of .png's
checked in with -kb? You never want to open those textmode.
However, it WOULD be good to use 'automode' on .cvsrc, .cvspass, and the
ROOT, ENTRIES, and REPOSITORY files in the CVS subdir of every project.
Is there a way to say "open this particular file in 'automode'" -- or
do you have to explicitly open it in "rt" for reading, and reopen in
"wb" for writing? Because if you have to do that, then we might as well
just open those particular files in "t" mode always...
CHANGES:
o updated to the 1.11.2 source
o requires gdbm-1.8.0-4
o NO new patches for textmode/binmode issues. Please help.
o Surf to
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/cvs/
and take a look at the results of my tests, in these files:
cvs-1.11.2-1.check.localpass
cvs-1.11.2-1.check.localfail
cvs-1.11.2-1.check.remotepass
cvs-1.11.2-1.check.remotefail
o There is also a more detailed summary of my experiments in the file
CHECK.SUMMARY, but I've reproduced that below.
o I have not gone thru all of the recent (and not-so-recent) bug
reports yet.
o I have made NO effort to get pserver working. (Yes, I remember that
somebody has successfully done so, and that I need to include their
recipe in the cygwin.README. I have not yet done so.
o Autoconf wackiness (see below)
--Chuck
Table of contents:
Notes
Brief Summary of Test Failures
Gory Test Results
For Extremely Gory Test Results, see the files
cvs-1.11.2-1.check.localpass
cvs-1.11.2-1.check.localfail
cvs-1.11.2-1.check.remotepass
cvs-1.11.2-1.check.remotefail
--------------------------------------------
NOTES
--------------------------------------------
NOTES:
(0) All tests run on W2k, NTFS, cygwin=ntsec, binary mounts
for EVERYTHING, including the build dir, src dir, and
/tmp.
(1) I have made no attempt to fix or find any text/binary issues
in the cygwin port of cvs.
(2) The old cvs-1.11.0-1 cygwin release failed these tests
(only :local: access was tested):
join-readonly-conflict (subtest 1)
modules (subtest 148) failed with a stackdump
errmsg1 (subtest 168)
binfiles3 (subtest 11)
rcs2 (subtest 7)
rcs3 (subtest 5)
So, the 1.11.2-1 actually performs better than 1.11.0-1; it
no longer fails the rcs2 and rcs3 tests. Of the five :local:
failures, four are no change from the earlier release. The
only "new" failure is modules6 -- but that test didn't exist
in 1.11.0, so it isn't a regression, per se.
Further, we now can test pseudo-remote access using the :fork:
protocol, which mimics all of the remote access code by
forking a new copy of cvs.exe as a "local server". In that
case, the only test differences are:
:fork: passes join-readonly-conflict
:fork: fails crerepos -- but that's expected
(3) for whatever reason, 'join-readonly-conflict' fails in
the local test, but passes in the :fork: (remote) test.
(4) coredumping is bad.
(5) local, stamps failed once, but running the test standalone
passed. Could be a race?
(6) Wackiness with autoconf. Although my configure.in and acinclude.m4
seem to be bug free themselves, autoconf is generating buggy
configures. (I mean, it totally loses track of what it's doing,
and puts in comments without '#' marks, drops 'help' text in the
middle of the running script, etc.) This is bad, and I'll report
it to the autoconf list. However, I have a "patch" of sorts
that I can use to fix the errors after running autoconf --
it's CYGWIN-PATCHES/post-autoconf-patch. This should not be
of any use to anyone, unless you start hacking the auto* files.
You may not be able to actually APPLY the patch, but it shows
you what errors happen, and approximately where to find them.
(The human brain 'fuzzy patch' function is much better -- if
slower -- than patch.exe's.)
However, WATCH OUT for the auto-rebuild of the configuration
files when you run 'make'. Make sure you run autoheader and
automake AFTER running autoconf and fixing up configure.
(7) Special 'targets' in the build script. After doing
cvs-1.11.2-1.sh conf, and build, you can also do:
cvs-1.11.2-1.sh check-local-pass
cvs-1.11.2-1.sh check-local-fail
cvs-1.11.2-1.sh check-remote-pass
cvs-1.11.2-1.sh check-remote-fail
check-local-pass runs all 115 local tests that I got successful
results for. Ditto check-remote-pass. However, check-local-fail
and check-remote-fail run only the (5 each) tests that failed
in my testing.
--------------------------------------------
BRIEF SUMMARY OF TEST FAILURES
--------------------------------------------
FAILED TESTS:
local, join-readonly-conflict (subtest join-readonly-conflict-10)
local, modules (subtest modules-148a0)
causes a coredump...
local, modules6 (subtest modules6-1)
local, binfiles3 (subtest binfiles3-11)
expected. 'admin -o' is disabled on windows/cygwin
local, errmsg1 (subtest 168)
remote, modules (subtest modules-148a0)
again, causes a coredump
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
ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
when testing in remote mode, crerepos uses :ext: instead of
:fork:. Therefore, I expect to fail, because I didn't have
rshd running.
--------------------------------------------
GORY TEST DETAILS
--------------------------------------------
LOCAL TESTS
FAILED 5
join-readonly-conflict
modules modules6
binfiles3
errmsg1
PASSED 115
version basica basicb basicc basic1 deep basic2
files spacefiles commit-readonly
rdiff diff death death2 rm-update-message rmadd rmadd2
dirs dirs2 branches branches2 tagc tagf
rcslib multibranch import importb importc
import-after-initial
join join2 join3
join-admin join-admin-2
new newb conflicts conflicts2 conflicts3
clean
modules2 modules3 modules4 modules5
mkmodules-temp-file-removal
cvsadm emptydir abspath toplevel toplevel2
checkout_repository
mflag editor errmsg2 adderrmsg
devcom devcom2 devcom3 watch4 watch5
unedit-without-baserev
ignore ignore-on-branch binfiles binfiles2
mcopy binwrap binwrap2
binwrap3 mwrap info taginfo config
serverpatch log log2 logopt ann ann-id
crerepos rcs rcs2 rcs3 lockfiles backuprecover
history
big modes modes2 modes3 stamps
sticky keyword keyword2 keywordlog
head tagdate multibranch2 tag8k
admin reserved
diffmerge1 diffmerge2
release
multiroot multiroot2 multiroot3 multiroot4
rmroot reposmv pserver server server2 client
fork
REMOTE TESTS: (uses :fork:, not :ext: or :pserver:)
FAILED 5
modules modules6
binfiles3
errmsg1 crerepos
PASSED 115
join-readonly-conflict
version basica basicb basicc basic1 deep basic2
files spacefiles commit-readonly
rdiff diff death death2 rm-update-message rmadd rmadd2
dirs dirs2 branches branches2 tagc tagf
rcslib multibranch import importb importc
import-after-initial
join join2 join3
join-admin join-admin-2
new newb conflicts conflicts2 conflicts3
clean
modules2 modules3 modules4 modules5
mkmodules-temp-file-removal
cvsadm emptydir abspath toplevel toplevel2
checkout_repository
mflag editor errmsg2 adderrmsg
devcom devcom2 devcom3 watch4 watch5
unedit-without-baserev
ignore ignore-on-branch binfiles binfiles2
mcopy binwrap binwrap2
binwrap3 mwrap info taginfo config
serverpatch log log2 logopt ann ann-id
rcs rcs2 rcs3 lockfiles backuprecover
history
big modes modes2 modes3 stamps
sticky keyword keyword2 keywordlog
head tagdate multibranch2 tag8k
admin reserved
diffmerge1 diffmerge2
release
multiroot multiroot2 multiroot3 multiroot4
rmroot reposmv pserver server server2 client
fork
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
2002-05-19 22:14 cvs-1.11.2 test release Charles Wilson
@ 2002-05-20 22:37 ` Charles Wilson
2002-06-15 4:20 ` Charles Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Charles Wilson @ 2002-05-20 22:37 UTC (permalink / raw)
To: Charles Wilson; +Cc: cygwin
Bump to 1.11.2-2. I've fixed the autconf hackery, so it works correctly
now. Thanks to Akim Demaille from the autoconf list for pointers...
All of the original warnings, provisos, etc apply to this "release".
Refer to the first message in this thread for more info.
--Chuck
FIXED:
> (6) Wackiness with autoconf. Although my configure.in and acinclude.m4
> seem to be bug free themselves, autoconf is generating buggy
> configures. (I mean, it totally loses track of what it's doing,
> and puts in comments without '#' marks, drops 'help' text in the
> middle of the running script, etc.) This is bad, and I'll report
> it to the autoconf list. However, I have a "patch" of sorts
> that I can use to fix the errors after running autoconf --
> it's CYGWIN-PATCHES/post-autoconf-patch. This should not be
> of any use to anyone, unless you start hacking the auto* files.
>
> You may not be able to actually APPLY the patch, but it shows
> you what errors happen, and approximately where to find them.
> (The human brain 'fuzzy patch' function is much better -- if
> slower -- than patch.exe's.)
>
> However, WATCH OUT for the auto-rebuild of the configuration
> files when you run 'make'. Make sure you run autoheader and
> automake AFTER running autoconf and fixing up configure.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
2002-05-20 22:37 ` Charles Wilson
@ 2002-06-15 4:20 ` Charles Wilson
2002-06-15 14:50 ` Nicholas Wourms
0 siblings, 1 reply; 8+ messages in thread
From: Charles Wilson @ 2002-06-15 4:20 UTC (permalink / raw)
To: Charles Wilson; +Cc: cygwin
Withdrawn.
(a) I've found a few bugs with this release
(b) in attempting to push upstream the patches our version of cvs has
been using for the past 18 months, I encounted stiff resistance. Okay,
not actually resistance -- just utter apathy. It seems that for all
intents and purposes the official cvs tree is NOT undergoing any active
development. I received a suggestion to look into cvsnt -- which has
now been backported to unix and is no longer a "windows only" port, as
of Feb 22, 2002.
This sounds like a good idea. In the long term, we should be able to
leverage the cvsnt support for
1) :pserver: running as a standalone service under LOCALSYSTEM, or
from inetd(?).
2) :ntserver: protocol, which uses NT authentication directly to
change user contexts, when operating within an NT domain
3) active development
Short term, I would like to create a "port" of cvsnt that compiles under
cygwin, and provides absolute compatibility with our cvs-1.11.0-1
package. For now, I'm not worried about :pserver:, daemon operation,
:ntserver:, etc. Just the basics -- which is what we have working now
with 1.11.0-1.
This means I need to cross-port our local cygwin changes, including the
gdbm database support for modules and val-tags in CVSROOT. The good
news: the cvsnt guys probably LIKE to receive patches.
Since the cvsnt port is currently based on 1.11.1, I will probably
package the cvsnt version as "t4est: cvs-1.11.1-X" and NOT
"cvsnt-1.11.1...". It might be a little confusing ("What? 'cvs' is not
cvs? It's cvsnt?") but this course of action would lead to far fewer
upgrade/downgrade problems in the long run (think: cvs-1.11.0-2 ==
empty, cvsnt-1.11.1-1 conflicts with cvs-1.11.0-1, no way to revert
back, etc)
Comments? Questions? Does anyone have experience with a *cygwin* port
of cvsnt (not just using the native cvsnt from within cygwin)?
--Chuck
Charles Wilson wrote:
> Bump to 1.11.2-2. I've fixed the autconf hackery, so it works correctly
> now. Thanks to Akim Demaille from the autoconf list for pointers...
>
> All of the original warnings, provisos, etc apply to this "release".
> Refer to the first message in this thread for more info.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
2002-06-15 4:20 ` Charles Wilson
@ 2002-06-15 14:50 ` Nicholas Wourms
2002-06-15 16:31 ` Charles Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Nicholas Wourms @ 2002-06-15 14:50 UTC (permalink / raw)
To: Charles Wilson; +Cc: cygwin
--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> Withdrawn.
>
> (a) I've found a few bugs with this release
>
> (b) in attempting to push upstream the patches our version of cvs has
> been using for the past 18 months, I encounted stiff resistance. Okay,
> not actually resistance -- just utter apathy. It seems that for all
> intents and purposes the official cvs tree is NOT undergoing any active
> development. I received a suggestion to look into cvsnt -- which has
> now been backported to unix and is no longer a "windows only" port, as
> of Feb 22, 2002.
>
> This sounds like a good idea. In the long term, we should be able to
> leverage the cvsnt support for
> 1) :pserver: running as a standalone service under LOCALSYSTEM, or
> from inetd(?).
> 2) :ntserver: protocol, which uses NT authentication directly to
> change user contexts, when operating within an NT domain
> 3) active development
Chuck,
This sounds all good and fine, but I am faced with the following issues
(after a *brief* scan of the cvsnt webpage):
A)Most projects use CVS, why the hell would the development of the CVS be
dead? Forgive me assumptions, but I thought the CVS project was one of
those key GNU projects? Or is everyone migrating to subversion now? It
seems like patches are being applied to the tree and some work is being
done. Perhaps you should apply to become a member of the CVS project so
you can just import your patches on your own. This apathy concerns me
greatly from both a linux and cygwin standpoint. I usually welcome
change, but I think sticking with the tried and true CVS might be a good
idea.
B)CVSnt on Windows seems to be nt/2000/xp-centric, what pitfalls can those
of us running ME/9x expect? (This may be a question for those who have
tried the cvsnt on cygwin
C)Will it be MingW or native Cygwin based? Although you did hint about
unix support, you didn't mention this explicitly...
D)Is there any functionality in the current Cygwin CVS that CVSnt wouldn't
be able to provide? (I.E. SSH, etc.)
Forgive these flurry of questions, but I feel compelled to ask for myself
and undoubtly for others, as well. I believe, no matter what, that you'll
arrive at the appropriate decision.
Cheers,
Nicholas
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
2002-06-15 14:50 ` Nicholas Wourms
@ 2002-06-15 16:31 ` Charles Wilson
0 siblings, 0 replies; 8+ messages in thread
From: Charles Wilson @ 2002-06-15 16:31 UTC (permalink / raw)
To: Nicholas Wourms; +Cc: cygwin
Nicholas Wourms wrote:
> This sounds all good and fine, but I am faced with the following issues
> (after a *brief* scan of the cvsnt webpage):
>
> A)Most projects use CVS, why the hell would the development of the CVS be
> dead? Forgive me assumptions, but I thought the CVS project was one of
> those key GNU projects? Or is everyone migrating to subversion now? It
> seems like patches are being applied to the tree and some work is being
> done. Perhaps you should apply to become a member of the CVS project so
> you can just import your patches on your own. This apathy concerns me
> greatly from both a linux and cygwin standpoint. I usually welcome
> change, but I think sticking with the tried and true CVS might be a good
> idea.
The following is a quote from the HACKING file in cvs:
> It is neither practical
> nor desirable for all/most contributions to be distributed through the
> "official" (whatever that means) mechanisms of CVS releases and CVS
> developers. Now, the "official" mechanisms do try to incorporate
> those patches which seem most suitable for widespread usage, together
> with test cases and documentation. So if a patch becomes sufficiently
> popular in the CVS community, it is likely that one of the CVS
> developers will eventually try to do something with it. But dealing
> with the CVS developers may be the last step of the process rather
> than the first.
And no, this ^^^^ is not boilerplate. They really mean it.
Also, there were about two years between 1.10.8 and 1.11.0. In the past
18 months, there have been two additional releases: 1.11.1 and 1.11.2.
That's pretty slow development. From the attitude on the list, I'd
guess that those releases were motivated by a desire to push changes the
core developers themselves had produced -- not to incorporate patches
"from the wider community". Apparently, FreeBSD had been trying to get
them to merge changes for years and finally gave up
The fact is, "cvs" is a fairly stable package. There are few bugs, and
they are unwilling to accept large patches (or even small ones) that MAY
destabilize it merely to allow compilation/operation on "extra"
platforms. They would prefer that "odd" platforms (like cygwin)
continue as forks, to protect the integrity of their "core" code. Well,
I'm tired of maintaining a fork.
The changes needed to run as a daemon on NT/cygwin -- and merely to
*run* as a native NT port -- are far more intrusive than they want.
> B)CVSnt on Windows seems to be nt/2000/xp-centric, what pitfalls can those
> of us running ME/9x expect? (This may be a question for those who have
> tried the cvsnt on cygwin
Remember, cvsnt code is almost entirely cvs code. When compiled as a
unix app, currently all the special nt-isms are #ifdef'ed out; you only
get the bugfixes (that the cvs folks haven't merged). So, at first,
there would be no difference on NT/2K/Xp and 9x/Me -- except those that
we already know about such as FAT vs. NTFS.
Later, as we start "turning on" some of the cvsnt-specific code,
additional differences MAY crop up in the daemon-mode code; you may not
be able to run a :pserver: or :ntserver: daemon on 9x/Me -- but the
cygwin kernel serves as a great "leveler", so we'll be able to
(hopefully) minimize those differences.
> C)Will it be MingW or native Cygwin based? Although you did hint about
> unix support, you didn't mention this explicitly...
cygwin. NOT mingw.
> D)Is there any functionality in the current Cygwin CVS that CVSnt wouldn't
> be able to provide? (I.E. SSH, etc.)
TBD. There are reports of difficulty using cvsnt + cygwin-ssh, but
that's (a) a "mingw" cvsnt. (b) perhaps not representative of the
universe of experience -- only those folks who can't get it to work
bother to post...
Otherwise, the codebase is basically cvs, so I'd be surprised if there
were big problems. There may be small wrinkles that we'd need to smooth
out...
> Forgive these flurry of questions, but I feel compelled to ask for myself
> and undoubtly for others, as well. I believe, no matter what, that you'll
> arrive at the appropriate decision.
Understood -- this is a big change to a core tool; I don't want to do
anything precipitous or without community support. Rest assured there
will be a long 'testing' period before the (current) cvs-1.11.0-1
package is retired.
--Chuck
FYI -- out of email contact until Tues...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
2002-06-17 13:15 ` Charles Wilson
@ 2002-06-18 4:59 ` Phil Dempster
0 siblings, 0 replies; 8+ messages in thread
From: Phil Dempster @ 2002-06-18 4:59 UTC (permalink / raw)
To: Charles Wilson; +Cc: cygwin
> > Personally, I prefer the inetd approach to a standalone daemon - seems
to me
> > there's too many services running already under Windows. The closer the
> > configuration is to Linux the better (since I work with both).
>
> That's an setup issue. You can run cvs as a standalone daemon --
> without inetd -- on linux, too.
True enough.
> (BTW, :pserver: and :ntserver: and inetd/standalone daemon server
> support is a future goal, not an immediate goal. The immediate goal,
> after appropriate discussion and testing here, is to get a
> cvsnt-on-cygwin package that works *as well as* and *totally plug-in
> replacement compatible with* the current cvs-on-cygwin package.)
>
> Then we worry about additional features.
>
> --Chuck
Agreed.
/phil
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
2002-06-17 12:55 Phil Dempster
@ 2002-06-17 13:15 ` Charles Wilson
2002-06-18 4:59 ` Phil Dempster
0 siblings, 1 reply; 8+ messages in thread
From: Charles Wilson @ 2002-06-17 13:15 UTC (permalink / raw)
To: Phil Dempster; +Cc: cygwin
Phil Dempster wrote:
> Personally, I prefer the inetd approach to a standalone daemon - seems to me
> there's too many services running already under Windows. The closer the
> configuration is to Linux the better (since I work with both).
That's an setup issue. You can run cvs as a standalone daemon --
without inetd -- on linux, too.
(BTW, :pserver: and :ntserver: and inetd/standalone daemon server
support is a future goal, not an immediate goal. The immediate goal,
after appropriate discussion and testing here, is to get a
cvsnt-on-cygwin package that works *as well as* and *totally plug-in
replacement compatible with* the current cvs-on-cygwin package.)
Then we worry about additional features.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cvs-1.11.2 test release
@ 2002-06-17 12:55 Phil Dempster
2002-06-17 13:15 ` Charles Wilson
0 siblings, 1 reply; 8+ messages in thread
From: Phil Dempster @ 2002-06-17 12:55 UTC (permalink / raw)
To: cygwin
I am wholeheartedly in favour of the cvsnt port approach.
Whilst I have managed to get cvs :pserver: running from inetd under Cygwin,
its not been without a reasonable amount of pain and a few annoying residual
quirks. I would also like to see :ntserver: support.
Personally, I prefer the inetd approach to a standalone daemon - seems to me
there's too many services running already under Windows. The closer the
configuration is to Linux the better (since I work with both).
/phil
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-06-18 7:53 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-19 22:14 cvs-1.11.2 test release Charles Wilson
2002-05-20 22:37 ` Charles Wilson
2002-06-15 4:20 ` Charles Wilson
2002-06-15 14:50 ` Nicholas Wourms
2002-06-15 16:31 ` Charles Wilson
2002-06-17 12:55 Phil Dempster
2002-06-17 13:15 ` Charles Wilson
2002-06-18 4:59 ` Phil Dempster
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).