A mailing list for issuezilla messages for the CVS project

Derek Price | 2 Aug 2005 15:44

CVS Development has Moved to savannah.nongnu.org.


The CVS developers would like to thank CollabNet on behalf of the CVS
community for their support and hosting these last several years.
However, the CVS developers have decided that it is in the best
interests of CVS development and the CVS community to move CVS
development to the open source development pages for non-gnu projects
hosted by the Free Software Foundation, at savannah.gnu.org
<http://savannah.nongnu.org>.

Please visit the new home page for the CVS project
<http://www.nongnu.org/cvs/>!

Users subscribed to mailing lists that were hosted at the cvshome.org
site will also need to subscribe to the new lists hosted at nongnu.org.

Users subscribed to info-cvs <at> gnu.org and bug-cvs <at> gnu.org should not need
to update their subscriptions to the new info-cvs <at> nongnu.org and
bug-cvs <at> nongnu.org mailing lists.  Settings and archives from these old
lists should have been preserved in the conversion to the new and the
old list names should remain as aliases for the new lists, at least for
the foreseeable future.

Visit the new mailing list information page
<http://savannah.nongnu.org/mail/?group=cvs> for archives and
subscription information.

Since much of the information and documentation on www.cvshome.org would
often become out of date due to lack of time on the part of the
authorized staff to handle all of the incoming suggestions for
improvement, much of the old cvshome.org site has been archived, with

(Continue reading)

headers

kgoeser | 2 Aug 2005 10:24

[Issue 262] Weird string insertion during commit!

https://ccvs.cvshome.org/issues/show_bug.cgi?id=262

------- Additional comments from kgoeser <at> cvshome.org Tue Aug  2 01:24:38 -0700 2005 -------
It's not a bug, it's a feature :) I never used keyword substition, sorry for any
inconvenience.

headers

dprice | 1 Aug 2005 16:32

[Issue 262] Weird string insertion during commit!

https://ccvs.cvshome.org/issues/show_bug.cgi?id=262

User dprice changed the following:

                What    |Old value                 |New value
================================================================================
                  Status|NEW                       |RESOLVED
--------------------------------------------------------------------------------
              Resolution|                          |INVALID
--------------------------------------------------------------------------------

------- Additional comments from dprice <at> cvshome.org Mon Aug  1 07:32:25 -0700 2005 -------
This is the behavior the documentation specifies for keyword substitution:
<http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Keyword_substitution#SEC99>.

headers

droopycom | 29 Jul 2005 05:13

[Issue 263] New - comminfo command line varies

https://ccvs.cvshome.org/issues/show_bug.cgi?id=263
                 Issue #|263
                 Summary|comminfo command line varies
               Component|ccvs
                 Version|current stable
                Platform|All
                     URL|
              OS/Version|Linux
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|commit
             Assigned to|issues <at> ccvs
             Reported by|droopycom

------- Additional comments from droopycom <at> cvshome.org Thu Jul 28 20:13:22 -0700 2005 -------
When a commit is done from different methods (:pserver: or :ext:), commitinfo
commands are called with different arguments making it impractical to have both
ssh and pserver access on the same repository.

When called from a pserver, commitinfo pass the username/login as the first
argument, the directory/repository as the seconds arg, and the filenames after that.
When called through SSH with the ext method, commitinfo pass the
directory/repository as the first argument and the filenames after that.

The documentation describes the second way, I could not find mention of the
username being passed to commitinfo through the commandline. The username is

(Continue reading)

headers

droopycom | 29 Jul 2005 05:32

[Issue 263] comminfo command line varies

https://ccvs.cvshome.org/issues/show_bug.cgi?id=263

User droopycom changed the following:

                What    |Old value                 |New value
================================================================================
                 Version|current stable            |1.11.1p1
--------------------------------------------------------------------------------

------- Additional comments from droopycom <at> cvshome.org Thu Jul 28 20:32:53 -0700 2005 -------
Actually, I could only test the pserver method with an 1.11.1p1 cvs binary.
I tested the ext method with both 1.11.1p1 (The exact same binary) and with a
freshly built 1.11.20.

So it could be a bug with the pserver method in 1.11.1p1, that has been fixed since.
Couldnot find any info though..

Thanks

[Changed version to 1.11.1p1]

headers

kgoeser | 27 Jul 2005 17:02

[Issue 262] New - Weird string insertion during commit!

https://ccvs.cvshome.org/issues/show_bug.cgi?id=262
                 Issue #|262
                 Summary|Weird string insertion during commit!
               Component|ccvs
                 Version|1.11.20
                Platform|PC
                     URL|
              OS/Version|Linux
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P2
            Subcomponent|commit
             Assigned to|issues <at> ccvs
             Reported by|kgoeser

------- Additional comments from kgoeser <at> cvshome.org Wed Jul 27 08:02:40 -0700 2005 -------
Create a file foo.tex, type the line "$State$", close it and add+commit it to
the repository. Change anything and commit the file again.

Now open the file: "$State$" has become "$State: Exp $"! The modification is
local and in the repository.

headers

rwoehler | 27 Jul 2005 15:37

[Issue 261] duplicate LogHistory warning in multi-root pserver

https://ccvs.cvshome.org/issues/show_bug.cgi?id=261

User rwoehler changed the following:

                What    |Old value                 |New value
================================================================================
     Attachment is patch|                          |Created an attachment (id=
                        |                          |109)
patch for "static int
                        |                          | gotone"

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

------- Additional comments from rwoehler <at> cvshome.org Wed Jul 27 06:37:56 -0700 2005 -------
Created an attachment (id=109)
patch for "static int gotone"

headers

rwoehler | 27 Jul 2005 15:33

[Issue 261] New - duplicate LogHistory warning in multi-root pserver

https://ccvs.cvshome.org/issues/show_bug.cgi?id=261
                 Issue #|261
                 Summary|duplicate LogHistory warning in multi-root pserver
               Component|ccvs
                 Version|1.12.12
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|server
             Assigned to|issues <at> ccvs
             Reported by|rwoehler

------- Additional comments from rwoehler <at> cvshome.org Wed Jul 27 06:33:49 -0700 2005 -------
If I set LogHistory in the cvs config files in a multi-root pserver installation
to anything but "all" every client operation aborts with "warning: duplicate
LogHistory entry found".

The problem is "static int gotone" in parseinfo.c, since the config file is read
for every root listed with the --allow-root command line option. The "gotone"
first appears in parseinfo.c 1.72.

Removing the "static" and moving the declaration to the top of parse_config()
fixed it (tested on Sparc Solaris 2.8, "make check" completes successfully).
However, having several "LogHistory=all" entries along with a single "other"

(Continue reading)

headers

lpoulsen | 14 Jul 2005 00:07

[Issue 260] New - TAG does not get logged to history file

https://ccvs.cvshome.org/issues/show_bug.cgi?id=260
                 Issue #|260
                 Summary|TAG does not get logged to history file
               Component|ccvs
                 Version|1.11.17
                Platform|PC
                     URL|
              OS/Version|Linux
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|history
             Assigned to|issues <at> ccvs
             Reported by|lpoulsen

------- Additional comments from lpoulsen <at> cvshome.org Wed Jul 13 15:07:32 -0700 2005 -------
I have been a happy user of CVS for 5+ years. I am now beginning to write
some scripts to generate changelogs. As I head into that, I find that for
the last several years there are no T records in CVSROOT/history.

I added an explicit "LogHistory=TOEFWUPCGMAR" to CVSROOT/config
and the next TAG created a line, but subsequent ones have not.

My server is 1.11.17 runnning on Linux (Fedora Core 3) and my
desktop clients are various Windows releases running the 1.10
(Halibut) client build. I see the same problem with :local: access 
and remote access using :server: access.

(Continue reading)

headers

mschwarzenberg | 5 Jul 2005 11:13

[Issue 259] New - cvs status fails to parse some entries in CVS/Entries

https://ccvs.cvshome.org/issues/show_bug.cgi?id=259
                 Issue #|259
                 Summary|cvs status fails to parse some entries in CVS/Entries
               Component|ccvs
                 Version|1.12.12
                Platform|Sun
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|status
             Assigned to|issues <at> ccvs
             Reported by|mschwarzenberg

------- Additional comments from mschwarzenberg <at> cvshome.org Tue Jul  5 02:13:03 -0700 2005 -------
The following CVS/Entries for two files test1.c, and test2.c

  /test1.c/1.8/Result of merge//
  /test2.c/1.1.2.2/*Fri Nov 19 13:34:50 2004//TTESTBRANCH

apparently resulting from 
  cvs update -A

(where test2.c exists only in the branch)
result in the following 
  cvs status test1.c test2.c

(Continue reading)

headers

dave_k | 29 Jun 2005 13:27

[Issue 108] Update should remove "Result of Merge" from Entries file

https://ccvs.cvshome.org/issues/show_bug.cgi?id=108

------- Additional comments from dave_k <at> cvshome.org Wed Jun 29 04:27:26 -0700 2005 -------

  Even more annoying, if you run "cvs update -C" on a file with conflicts, it
also fails to remove the merge conflict indicators.  This leads to the following
nonsensical sort of output from cvs:

dk <at> mace /usr/build/src/newlib/libm/common> cvs update -C s_lrint.c
Enter passphrase for key '/home/dk/.ssh/id_rsa':
(Locally modified s_lrint.c moved to .#s_lrint.c.1.2)
cvs update: warning: s_lrint.c was lost
cvs update: move away ./s_lrint.c; it is in the way
C s_lrint.c
dk <at> mace /usr/build/src/newlib/libm/common>

  It boggles the imagination to see cvs move something, then complain it's lost
it, then complain it's still there and in the way, then claim the clean checkout
has a conflict!

    cheers, 
      DaveK
--

-- 
Can't think of a witty .sigline today....

3	August 2005
7	July 2005
15	June 2005
45	May 2005
10	April 2005
2	March 2005