Thanks so much for the reply Larry.
Statistics
-------------------------
Locally Modified = 43
Needs Merge = 458
Needs Patch = 256
What would the example below tell you at first glance:
(staceym is the id of our contractor...asrs_dev is the id of our
application owner)
(do timestamps or ownership have anything to do with this problem?
Somehow the CVS-related timestamps are off from the system time by 5
hrs)
Version 1.2 was in place prior to the upgrade.
Contractors took all our source. Didn't actually modify
the file, but they hosed it up when they transferred it back to us
(^M's). I did not catch this problem before I
Version 1.2 was prior to the contractor upgrade
(no ^M's)
Version 1.3 was from me committing the
transferred file (with ^M's)
Since then, (Oct. 8) we ran a search and replace
all throughout the project...resulting in the current file (which is
identical to 1.2.
CVSROOT = /users_dev/CVS
[CUX028] /users_dev/asrs_app#> lt
$CVSROOT/phx/db/dat/progload.dat,v
-rwxrwxr-x 1 asrs_dev asrs_app 2959 Sep 21 17:04
/users_dev/CVS/phx/db/dat/progload.dat,v
[CUX028] /phx_dev/db/dat#> lt progload.dat
-rw-rw-r-- 1 staceym asrs_app 1069 Oct 8 18:50
progload.dat
[CUX028] /phx_dev/db/dat#> grep progload CVS/Entries
/progload.dat/1.2/Mon Oct 8 23:50:54 2007//
[CUX028] /phx_dev/db/dat#> cvs status -v progload.dat
===================================================================
File: progload.dat Status: Needs Patch
Working revision: 1.2 Mon Oct 8 23:50:54 2007
Repository revision: 1.3
/users_dev/CVS/phx/db/dat/progload.dat,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
PRE_ECHO_BASELINE (revision: 1.2)
PRE_SHOPTICKET (revision:
1.1.1.1)
initial_load (revision:
1.1.1.1)
phx_grapevine (branch: 1.1.1)
[CUX028] /phx_dev/db/dat#> cvs log progload.dat
RCS file: /users_dev/CVS/phx/db/dat/progload.dat,v
Working file: progload.dat
head: 1.3
branch:
locks: strict
access list:
symbolic names:
PRE_ECHO_BASELINE: 1.2
PRE_SHOPTICKET: 1.1.1.1
initial_load: 1.1.1.1
phx_grapevine: 1.1.1
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------
revision 1.3
date: 2007/09/21 22:04:17; author: asrs_dev; state:
Exp; lines: +28 -28
File Modified for ECHO Baseline
----------------------------
revision 1.2
date: 2005/12/20 00:37:34; author: jwf; state: Exp;
lines: +3 -3
ASRS Server Upgrade - variable mountpoints.
----------------------------
revision 1.1
date: 1999/09/17 21:37:06; author: lelling; state:
Exp;
branches: 1.1.1;
Initial revision
----------------------------
revision 1.1.1.1
date: 1999/09/17 21:37:06; author: lelling; state:
Exp; lines: +0 -0
initial import
========================================================================
=====
-----Original Message-----
From: Larry Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 15, 2007 10:51 AM
To: Fierke, John
Cc: [email protected]
Subject: Re: Have lots of "needs patch" and "needs merge"
Fierke, John writes:
>
> I am currently running (don't laugh) version 1.11 on a solaris
machine.
That version is *very* old -- I strongly suggest you upgrade to the
latest stable version (1.11.22), which contains many bug fixes. But
that's not the source of your problem.
> Something I did (at least I *THINK* it was me) caused most of the
> files to now show as either "Needs Merge" or "Needs Patch"...I CANNOT
> identify a pattern behind why some are "merge" and others are "patch".
> We had an issue with a few of the files that the contractor
> transferred to our site having carriage returns in them (^M's) - we
> removed fixed those files. And there are even files that show
"Locally modified".
"Needs Merge" indicates that the file has been modified in the working
directory and there's also a newer version in the repository than what
was checked out, so the changes need to be merged. "Needs Patch" means
that the local file has not been modified but there's a newer version in
the repository that should replace it. "Locally Modified" means that
the local file has been modified but there's no newer version in the
repository.
>From what you said you did, I suspect that the files from the contractor
that you overlaid included the CVS/Entries files that CVS uses to record
the repository version and timestamp for each file in the working
directory. If that's the case and that data is actually correct, then
what CVS wants to do is exactly the right thing to do, assuming you want
to keep the changes that have been made to the repository since the
contractor got the original files. You should do an "update" to handle
the merges and patches, resolve any conflicts, test everything, then
commit the changes. If the data is not correct, or you don't want to
keep the repository changes, then you need to start over with a new
working directory and be sure not to overlay the CVS/Entries files.
-Larry Jones
What better way to spend one's freedom than eating chocolate cereal and
watching cartoons! -- Calvin
