|Subject:||RE: Have lots of "needs patch" and "needs merge"|
|Date:||Thu, 15 Nov 2007 11:41:50 -0700|
Thanks so much for the reply Larry.
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)
PRE_ECHO_BASELINE (revision: 1.2)
PRE_SHOPTICKET (revision: 188.8.131.52)
initial_load (revision: 184.108.40.206)
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
keyword substitution: kv
total revisions: 4; selected revisions: 4
date: 2007/09/21 22:04:17; author: asrs_dev; state: Exp; lines: +28 -28
File Modified for ECHO Baseline
date: 2005/12/20 00:37:34; author: jwf; state: Exp; lines: +3 -3
ASRS Server Upgrade - variable mountpoints.
date: 1999/09/17 21:37:06; author: lelling; state: Exp;
date: 1999/09/17 21:37:06; author: lelling; state: Exp; lines: +0 -0
From: Larry Jones [mailto:address@hidden]
Sent: Thursday, November 15, 2007 10:51 AM
To: Fierke, John
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.
What better way to spend one's freedom than eating chocolate cereal and watching cartoons! -- Calvin
|[Prev in Thread]||Current Thread||[Next in Thread]|