The win build for cvs1-12-x fails with :ext: and CVS_RSH set to ssh
(plink.exe). The last working cvs1-12-x version is 1.12.8, newer builds fail.
Example:
cvs -r status -v BUGS.txt
cvs.exe [status aborted]: reading from server: No such file or directory
I have verified this behavior with
No comments on this issue?
Does anybody else experience this behavior?
Frank
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Hi,
when running rlog on the cvshome repository, the command fails in
the src subdir, telling there are administrative files missing:
cvs rlog -d 2005-02-16 13:41:10= -N -S ccvs
cvs rlog: Logging ccvs
cvs rlog: Logging ccvs/contrib
cvs rlog: Logging ccvs/contrib/elib
cvs rlog: Logging
the select
could be skipped ...
Regards
Frank
Derek Price wrote:
| Frank Hemer wrote:
| | It seems I have tracked down the failure - Find below a patch
|
| that | fixes this issue:
|
|
| I don't like this patch. It must be in the wrong direction. I
| refuse to believe
The basic problem, as Frank Hemer has described it, is that there are
some conditions where the Windows client can expect to be in
non-blocking mode yet fail to really be in non-blocking mode, causing
a hang. Frank has yet to send a script reproducibly demonstrating the
failure.
If you send
On Sunday 20 February 2005 16:03, you wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Hemer wrote:
| The basic problem, as Frank Hemer has described it, is that there
| are some conditions where the Windows client can expect to be in
| non-blocking mode yet fail to really
On Monday 21 February 2005 22:42, Conrad T. Pino wrote:
The following patch fixes all build errors.
I don't claim it works and I don't claim it doesn't work.
It works for me - I have just testet the same patch;-)
Frank
___
Bug-cvs mailing list
In response to an old thread/message from dec 04,
(http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I would
like to add some suggestions:
The cvsnt commitid feature for the log cmd is a very neet feature because it
allows to collect all versions that belong to a single commit.
Maybe there is an easy solution for this, but I have not yet
found it.
What about taking some code/adapt code from cvsnt?
I have not taken a detailed look at it, but there must already be some
abstraction done ...
Frank
___
Bug-cvs mailing list
On Wednesday 23 February 2005 00:31, Derek Price wrote:
Frank Hemer wrote:
| In response to an old thread/message from dec 04,
| (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I
| would like to add some suggestions:
|
| The cvsnt commitid feature for the log cmd is a very
On Wednesday 23 February 2005 00:31, Derek Price wrote:
Frank Hemer wrote:
| In response to an old thread/message from dec 04,
| (http://lists.gnu.org/archive/html/bug-cvs/2004-12/msg00150.html) I
| would like to add some suggestions:
|
| The cvsnt commitid feature for the log cmd is a very
I was just glancing at that patch and I think I can implement what
Steve did much more succinctly, so I'm going to take a shot at it.
The most important thing for your patch is probably to use the naming
scheme: `.XXX'.
So I'll wait for your commit then.
Regards
Frank
Glancing at your doc and test cases, I gather that this change just
tags the revisions and does not yet provide a way to get at the
information for diffs/merges/etc.?
That's right. I didn't like the way cvsnt evaluates tages - or better - the
commitid tags. Because this is related to the
How about .commitid./commitid/ (where /commitid/ is replaced with
the actual commitid), with @ as an acceptable alias for .commitid.
for compatibility with CVSNT? Then .commitid./commitid/.previous or
@/commitid/ could be used to specify the previous revision.
So the '.' (dot) would
On Saturday 26 February 2005 00:27, Derek Price wrote:
Frank Hemer wrote:
| I was just glancing at that patch and I think I can implement
| what Steve did much more succinctly, so I'm going to take a shot
| at it. The most important thing for your patch is probably to use
| the naming scheme
On Saturday 26 February 2005 21:06, Derek Price wrote:
Frank Hemer wrote:
| On Saturday 26 February 2005 00:27, Derek Price wrote:
| Frank Hemer wrote: | I was just glancing at that patch and I
| think I can implement | what Steve did much more succinctly, so
| I'm going to take a shot
| Ooops, I think I'm too fast;-) I have just finished adding '.trunk'
| as a trunk-branch substitution, 'cause I happened to note that this
| fits perfectly into my patch. I have already used the above
| mentioned splitting - so now '.prev' might even be added more than
| once and works
| If tags with '@' at the begining are used they're added in the
| cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was
| wrong). If the .commitid is used, they're cached as
| '.commitid.xxx', but this could be changed as you suggested.
I think this would be a good idea,
| Also, commitids should be cached at commit time as well as when
| they are found in RCS files. CVS started doing this on tag
| creation for other branches and tags a few releases back It's
| silly to wait for the first update to insert them into val-tags -
| it only triggers an unneeded
Note that when the final flag to tag_check_valid() is true,
tag_check_valid() skips step 2 (the recursive repository check) and
jumps to adding the tag to val-tags.
Is this a security issue, meaning to reduce server load if lots of invalid tags
are requested?
However, I have implemented it
On Wednesday 02 March 2005 17:18, Derek Price wrote:
Frank Hemer wrote:
| On Wednesday 02 March 2005 08:11, Mark D. Baushke wrote:
| Hi Frank,
|
| I am looking forward to your feature...
|
| :-)
I'm looking forward to this too. I just have one quibble, with your
usage of .root. The CVS
Hi Derek,
Mark D. Baushke wrote:
| Frank Hemer [EMAIL PROTECTED] writes:
| However I didn't have a better idea. Using .base instead can be
|
| similar
|
| miss-interpreted since there is BASE. How about replacing '.root'
| with '.tail', and replacing '.origin' with '.root'?
|
| Hmmm
| A rational way. As a second step I would suggest to change the
| extensions (.prev, .next, .xxx) to be allowed in head position too,
| but I'm note sure where the sandbox tag gets processed. If
| translate_tags() could take that into account, its not a big deal
| ... Where is this state
On Saturday 05 March 2005 00:15, Derek Price wrote:
Derek Price wrote:
Mark D. Baushke wrote:
| Therefore, I suppose that there could be a need for .origin to be
| the first revision on TRUNK
This would seldom mean much across multiple files, so I still think
.origin should not be
On Tuesday 08 March 2005 16:37, Derek Price wrote:
Jim.Hyslop wrote:
| Jim Meyering wrote:
| Is it an option to use a more modern/POSIX-compliant development
| environment on Windows? I know that Cygwin now has fchdir and it
| looks like MKS has support for it, too.
|
|
| If you opt to
);
+ vers_ts-tag = xstrdup (vers_ts-vn_rcs);
+ }
}
/*
the patch
Best regards
Frank Hemer
--
- The LinCVS Team -
http://www.lincvs.com
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman
On Wednesday 09 March 2005 15:50, Derek Price wrote:
Frank Hemer wrote:
| Here is a more detailed description of the tag-extensions:
Mostly this sounds great, with the few questions/exceptions that I
have noted.
Could you write the final version up as a patch to doc/cvs.texinfo?
I
Hi,
the 1.12.x series contains the http tunnel web proxy patch. This patch
originaly allowed to specify the proxy and proxyport using environment
variables (PSERVER_PROXY) in the form of 'my.proxy.server[:PORT]', in
addition to specifying it in the CVSROOT. This has the advantage of not
| | '.origin': Will always resolve to the very first revision. If a
| |
| | file has been added on a branch, .origin will resolve to the
|
| first | revision on that branch, otherwise it will follow the
| mainline. | | '.root': Will resolv to the predecessor of the
| first revision on |
On Wednesday 09 March 2005 21:08, Mark D. Baushke wrote:
Derek Price [EMAIL PROTECTED] writes:
In the case where the information came out of the directory CVS/Tag
file, it becomes available in vers-nonbranch, but not otherwise.
In other cases, the RCS file gets parsed anyhow, but only on
Hi,
I have noticed that cvs add foo generates an initial revision number of 2.1 if
there exist files in the repository that have revision numbers =2.x. Is this
expected behavior?
Regards
Frank
--
- The LinCVS Team -
http://www.lincvs.com
___
| I agree. I would really like a way to replace the idioms
|
| cvs tag foo-bp cvs tag -b foo-branch cvs up -r foo-branch .lots
| of changes and commits cvs diff -rfoo-bp -rfoo-branch
|
| with something like:
|
| cvs tag -b foo-branch cvs up -r foo-branch .lots of changes and
|
On Thursday 10 March 2005 19:56, Derek Price wrote:
Frank Hemer wrote:
| Hold on ... it seems I have found a workaround for this:
|
| /* If a file was added on the trunk, and it is added on * a branch
| in a second step, the '1.1.2.1' revision is * dead, and timestamp
| of 1.1 and 1.1.2.1
Frank,
I've committed a few new changes and the tests are passing again,
including your new tag-ext tests.
I also added a FIXME comment or two. Please take a look, especially at
the one in RCS_getprevious.
Well, according to my comment above your FIXME (RCS_getprevious) the code does
| I've spotted several errors and omissions so far and have cause
| to wonder if the only reason tag-ext passes currently is that
| testing is not complete. Please see what you can do about adding
| more tests.
|
| Could you provide more details what exactly fails? Regarding your
| changes
Yes. It is ok to send intermediate patches.
Ok, here's the next. See src/ChangeLog for details -
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.3165.2.5
diff -u -r1.3165.2.5 ChangeLog
---
I cannot get :gserver: on the 1.12.x head branch to work:
When using a 1.12.x client with a 1.11.x server, some data is received and
then the client hangs (waits?) forever (for EOF?).
When using a 1.11.x client with a 1.12.x server, it outputs:
cvs [status aborted]: recv() from server
I'd like to see my latest patch from 2005-04-08 18:03 beeing commited to the
newtags branch so I can continue working on it ...
Regards
Frank
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
On Tuesday 19 April 2005 20:41, Derek Price wrote:
I'd like to see my latest patch from 2005-04-08 18:03 beeing
commited to the newtags branch so I can continue working on it ...
Sorry. I ran the tests and saw them pass the other day but I had been
having a hard time finding the time to
On Thursday 21 April 2005 15:57, It's me FKtPp ;) wrote:
hi,
I used to access some repository, which was in a debian sarge system,
from a Winodws machine via cvs.exe and plink.exe. But when I upgrade
my cvs from 1.12.8 to 1.12.11 and 1.12.12, It doesn't work. After I
issue any cvs commands
On Tuesday 21 June 2005 17:13, Richard M. Stallman wrote:
I am trying to bring about a fix for the bad interaction between
CVS and SSH that causes data to be lost?
See http://lists.gnu.org/archive/html/bug-cvs/2002-07/msg00423.html
for a good explanation.
After studying that message, I
41 matches
Mail list logo
