Ken Ballou writes:
> I believe I have found a bug in the CVS merge algorithm, as demonstrated
> by the attached sample files.
...
> the resulting file has two copies of the rule to make target
> "cleanest", and there are no merge conflict indicators!
I reproduced your results, but I do not thin
I believe I have found a bug in the CVS merge algorithm, as demonstrated
by the attached sample files. There are three versions of a file named
"bug": revision 1.1, revision 1.2, and revision 1.1.2.1 (branch named
"branch"). If the working revision of the file is 1.2, the command "cvs
update -jbr
See answers below.
Best regards,
Damjan
-Original Message-
From: [EMAIL PROTECTED] [mailto:lawrence.jones@;eds.com]
Sent: Monday, November 11, 2002 5:39 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: CVS bug?
Damjan Zemljic writes:
>
> I created a branch on one fil
Hi,
I created a branch on one file just to have that tag in CVS repository.
Nothing has been commited yet to this branch. Then I've checkouted
files with:
cvs co -R -f -r
(from branch and missing from HEAD)
After that, I patched the files of module and wanted to commit changes
(excpeted to co
Good morning,
I'm facing a serious problem with CVS.
After the last checkin of a fundamental file of my project, CVS is not
able anymore to work on it. It make impossible for us to continue
with the parallel development.
Issuing any command on this file results in aborting CVS with the
following
Hello Derek,
i thank you very much for your answer.
> I see where you're coming from, but the way -n currently works, when CVS
> would have tried to create a directory, it stops before it knows whether
> it would have been empty or not.
Ok, i see that changing this report-behaviour needed de
Gert Brinkmann wrote:
> Hello,
>
> the following might be a CVS bug. I already have reported it, but
> there was no answer. Does this mail really reach someone?
Sometimes, we think it makes it somewhere. The sentience of the beings
recieving it may be debatable.
> (We hav
[EMAIL PROTECTED] wrote:
>G, still some whitespace problems.
>One more time with the attachment gzipped...
>
As stated in the HACKING file in the top level of the CVS source
distribution, it's much easier to get patches accepted with sanity.sh
test cases, ChangeLog entries, and when approp
G, still some whitespace problems.
One more time with the attachment gzipped...
rcs_patch.gz
Description: GNU Zip compressed data
Hmm.. couldn't read back the patch correctly from the
list myself so here we go once again. This time with
the patch as an attachment also.
Index: rcs.c
===
RCS file: /usr/local/cvsroot/cvs_src/src/rcs.c,v
retrieving revision 1.1.1.
Hi,
what you have found here is a bug in rcs.c that still
hasn't been fixed in the latest stable release. (1.11.2)
Quite some time ago I posted a patch here for 1.11.1p1
but that didn't get in :-(
Anyway, here is something that works for 1.11.2
Index: rcs.c
===
Hello,
I found an error in CVS, version 1.10.7. It is related to the feature of vendor
branches. If using these to track the progress of an external source, CVS does
not correctly handle date information. In specific, when a file was only changed
by the vendor for some time, and then a private ch
Hi,
> I got a problem with cvs remove command that I think is a bug in CVS, but I'm not
>sure.
>
> A scenario is needed to describe the problem:
>
> Prereq:
> Suppose you got two branches created out of main branch.
> The first branch is called REL1 and the second is REL2 and main is still
> u
Submitter-Id: net
Originator:
Organization: MandrakeSoft
Confidential: no
Synopsis: some cvs sub commands don't work when using LockDir and symbolic link to
repository
Severity: non-critical
Priority: low
Category: cvs
Class: sw-bug
Release: 1.11.1p1
Environment:
System: Linux skywalker.
Hi, cvs developers.
i'm using cvs 1.11 for windows nt and this client do not want to use
any port (in CVSROOT env variable) other than default.
--
Maxim Z. Kutniy
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-
mohan DR writes:
>
> Content-Type: text/html
Don't send HTML to the mailing list.
> CVS is able to checkin a large file 24MB. But when the file is
> modified and a new file is checked in, the commit operation fails with
> the following error.
>
> cvs [server aborted]: out of memory; can not real
Hello,
CVS is able to checkin a large file 24MB. But when the file is modified and a new file is checked in, the commit operation fails with the following error.
cvs [server aborted]: out of memory; can not reallocate 25863838 bytes
*CVS exited normally with code 1*
Is there a work aroun
[EMAIL PROTECTED] writes:
>
> I was not complaining about wrong text in the sources checked out or in the
> repository
> (this might be caused indeed by network problems),
> but I was complaining about the internal integrity of the CVS repository.
> The internal syntax/structure of the repository
Hi,
I'd like to report a bug in CVS version 1.10.7 (client) running on Windows
2000 Professional.
My CVS version does not trap clicks on Ctrl+Break. The result of this is
that the CVS locks in the repository are not cleaned up, thus preventing
users from running CVS commands on those directories.
_
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
kishor kandrup <[EMAIL PROTECTED]> writes:
>Hi mailing list ppl,
>
>I have a query about cvs,i'll appreciate reply from you.
>
>I am facing problem as described below :
>
>1.)I succeded in adding file of 300 plus MB on CVS server (binary mode).
>2.)I checked it out ,made so
Hi mailing list ppl,
I have a query about cvs,i'll appreciate reply from you.
I am facing problem as described below :
1.)I succeded in adding file of 300 plus MB on CVS server (binary mode).
2.)I checked it out ,made some changes and commited(331587857 bytes) ,it
was
stored o
If a file is added initially to
the main CVS tree, everything works fine. If a file is added initially to a
maintenance branch, however and the file is later merged into the main line
using "update -j" and committed to the head, subsequent attempts to to run
"update -j" will fail with the er
Fernando Lopez writes:
>
> $ cvs admin -l config.cpp
> RCS file: /boot/home/repositoriocvs/gnu/guavac/config.cpp,v
> 1.3 locked
> done
>
> When I got this file from another sandbox it's read-write
I think the confusion is that admin -l makes the file read-only for
other *users*, not the
Hi I'm writting a CVS tutrorial for a spanish language BeOS developers
comunity at www.beprogramadores.org, and I was probing CVS 1.10.8 (the
last version) for BeOS who I got at www.geekgadgets.org and there is a
bug acording to Per Cederqvist tutorial because he told at section10
than CV
Philippe Barnetche writes:
>
> Is this normal to put the trailing dot ? I mean, was it all my fault to think
> that a single trailing slash would be enough ?
No, CVS is overly aggressive in removing trailing slashes from CVSROOT.
It does that so that it can do simple string comparisons on file
Damn !
It works !
We've spent all day moving our modules to /modules...
Is this normal to put the trailing dot ? I mean, was it all my fault to think
that a single trailing slash would be enough ?
Thank you, and again, happy new millenium !
Philippe
Le Mercredi 03 Janvier 2001 16:37, vous m
Philippe Barnetche writes:
>
> :ext:user@host:/
>
> The trailing slash seems to be a problem because some cvs commands work
> (log,commit...) but other doesn't (checkout, diff...). The error message is:
> Bad CVSROOT :ext:user@host:
Try adding a trailing dot to your CVSROOT: ``:ext:user@host:/
ad CVSROOT :ext:user@host:
(the trailing slash is missing). I've got the error on both debian potato and
mandrake.
Actually, when I run cvs manually, with the environment variable set to
:ext:user@host:/
cvs status give me the same error, so I presume this is a cvs bug.
But when I run cvs -d:ext:use
>Submitter-Id: net
>Originator:Steven Lass
>Organization: WorldCom
>Confidential: no
>Synopsis: redhat 7.0 error: cannot create_adm_p /tmp/cvs-serv22619/src
>Severity: critical
>Priority: high
>Category: cvs
>Class: sw-bug
>Release: cvs-1.11
>Envir
Kuros Yalpani wrote:
> For some strange reason, the cvs server (Unix) makes a decision about case
> insensitivity
> and it ought not. The cvs client should decide when two filenames are "equal" and
> not the
> server. The server is not doing anything wrong by being case sensitive.
I didn't code
Kuros Yalpani wrote:
> Thanks Derek. Please glance at the trace that I included below. I do a 'cvs commit'
> there after a 'cvs remove ' and yet it appears that still exists
> in the "Entries" file. Is this the correct behaviour?
After further examination, I think this is the correct behavior,
Kuros Yalpani wrote:
> Thanks for calling back Derek! You seem to agree that there could be a problem.
> Given my little knowledge of CVS: I think that (1) the cvs server has no problem
> with case sensitivity. (2) when I do a "cvs remove fileA.c", fileA.c is moved into
> the Attic on the server
Hello,
I've discovered a pitfall with moving files as explained in the CVS manual and info.
It happens when you're trying to move a binary file which is not a type listed in
cvswrappers.
If you do the following procedure, everything is a-ok:
cvs add -kb binary_file.xxx; cvs commit
mv binary_
Kuros Yalpani wrote:
> Michael Peck schrieb:
>
> > Because NT is not case sensitive, CVS is told by the OS that the file already
> > exists when you try to add the new file (with the corrected case).
This might be fixable on the client side and though I'm not convinced the behavior is
incorrect,
> > C:\cvs_workdir\javaproj>cvs add Bsort.java
> > > > cvs server: re-adding file Bsort.java (in place of dead revision 1.2)
> > > > cvs server: use 'cvs commit' to add this file permanently
> > > > C:\cvs_workdir\javaproj>cvs commit
> >
cvs server: use 'cvs commit' to add this file permanently
> > > C:\cvs_workdir\javaproj>cvs commit
> > > cvs commit: Examining .
> > > ? CVS
> > > RCS file: /sdb/cvs/test/javaproj/Bsort.java,v
> > > done
> > > Checking in Bsort.java;
&g
gt; RCS file: /sdb/cvs/test/javaproj/Bsort.java,v
> > done
> > Checking in Bsort.java;
> > /sdb/cvs/test/javaproj/Attic/bsort.java,v <-- bsort.java
> > cvs [server aborted]: can't stat bsort.java: No such file or directory
> > cvs commit: saving log message in C:\TEMP\7
> >
> > C:\cvs_workdir\javaproj>
> >
> > I would appreciate your comments on this. Thanks very much
> >
> > Kuros Yalpani
> > MGM-EDV
> > Munich, Germany
> >
> > ___
> > Bug-cvs mailing list
> > [EMAIL PROTECTED]
> > http://mail.gnu.org/mailman/listinfo/bug-cvs
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
Hi! I want to report something that appears to be a bug. We are
running CVS in a client/pserver configuration (WinNT clients/Linux
server). I noticed the following problem when trying to rename a file
in the repository to a new name that differs only in its case from the
old filename, as illustrat
Kuros Yalpani writes:
>
> Q: Why do I think that this is a bug?
> A: CVS import ought not force me to use its default ignore list
Yes, this is a known bug in client/server mode. Unfortunately, it is
not easily fixed.
-Larry Jones
You just can't ever be too careful. -- Calvin
_
Hallo! I recently installed cvs (1.10.7) for our company of ~50
developers in a pserver configuration. The clients are WindowsNT
and the server is a SUSE linux.
I fell victim to the following constraints:
1) We want to import file-types the 'cvs import' command ignores by
default.
2) We want to ma
Michael S. Tsirkin writes:
>
> I am using CVS 1.10.8 on Linux.
> When I do commit, sometimes garbadge in put in the
> "Tag" field in the file.
> I think this is a symptom of a more serious bug.
> This only happends when LockDir and PreservePermissions
> are enabled.
The PreservePermissions code
Hello!
I am using CVS 1.10.8 on Linux.
When I do commit, sometimes garbadge in put in the
"Tag" field in the file.
I think this is a symptom of a more serious bug.
This only happends when LockDir and PreservePermissions
are enabled.
Try the following:
/tmp>mkdir /tmp/cvsroot
/tmp>cd cvsroot/
/
Being a paranoid sysadmin who runs his cvs server for the world to poke
and prod at, I compile CVS statically and stick it in its own chroot()'d
filesystem with a little wrapper program.
Doing this works fine up until the final link:
/usr/lib/libc.a(regex.o): In function `regex_compile':
/usr/s
>Submitter-Id: net
>Originator: & McLachlan
>Organization:
net
>Confidential: no
>Synopsis: cvs co -d does not function correctly using client/server.
>Severity: serious
>Priority: medium
>Category: cvs
>Class: sw-bug
>Release: cvs-1.10.8
>Environmen
[EMAIL PROTECTED] (Cathy Li) writes:
> Win95/NT is as a client, talking to CVS server on Linux box using
> password authentication. The client running NT works properly. The
> client running Win95/98 said " can't find out home directory" when
> trying to login. The cvs version is 1.10. If someone
Win95/NT is as a client, talking to CVS server on Linux box using
password authentication. The client running NT works properly. The
client running Win95/98 said " can't find out home directory" when
trying to login. The cvs version is 1.10. If someone knows how to fix
it, please help me. Thanks.
47 matches
Mail list logo
