[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bizarre update behaviour
Re: Bizarre update behaviour
Thu, 14 Mar 2002 16:47:09 -0500
There are two separate problems here. The mysterious clobbering
of changes is *not* responsible for what you saw when you tried
to revert; the latter is expected behaviour.
On Thu, Mar 14, 2002 at 12:07:15PM -0500, James Hughes wrote:
> My first problem is that the change in rev 1.69 has disappeared sometime
> between 1.69 and 1.71. I've posted before about code getting clobbered
> and basically been told it's human error, which I can buy, but still,
> it's mystifying how 3 successive changes by the same developer result in
> changes disappearing.
More information is called for. Could you please make available
a complete "cvs log" of that file? Feel free to delete the
user-written log messages if they're confidential, but leave in
all the CVS-generated stuff (revisions, dates, lines of ---- and
====, etc.). Also leave in any tags. (If it's too big to
politely post, put it up on a Web or FTP site instead.)
Which of those two revisions was it that clobbered the 1.69
What else happened between 1.69 and 1.71 -- copying your sandbox,
FTPing it to a laptop, moving the repo to a new location.
Basically, *anything*, however innocuous it might seem, other
than editing the file locally on the client machine, and CVS
"update" and "commit" commands. Is there *any* chance you were
working on the file in two windows at once? That could lead to
this race condition:
Window 1 Window 2
Now, on to problem 2...
> However, what's more mystifying is what happened when I tried to restore
> the change that I had made in 1.69:
> doing this
> cvs up -r 1.69
> resulted in 6 files with the message,
> *.c is no longer in the repository
> And not only that, but those same files had magically disappeared from
> the working directory.
Of course. Not all of the files in the project *have* 69
revisions. This is what happens to each file that has fewer.
Even for the files that have that many, rev. 1.69 is probably not
where you want to revert to. Updating multiple files to a
specific revision number, instead of a tag or date, is almost
> Repeated updates and a fresh checkout over the
> existing directory fail to pull them down again.
Because "cvs up -r 1.69" made the revision number sticky. That
would have been a problem even if you'd only updated the one
file. But stickiness is per-sandbox, which is why you saw the
> However, creating a new
> directory and doing a fresh 'cvs co' pulled everything down as expected.
I think what you wanted was one of these:
cvs up -j1.71 -j1.70 dps.pc
cvs up -j1.70 -j1.69 dps.pc
depending on which revision actually did the damage.
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
"Outlook not so good." That magic 8-ball knows everything!
I'll ask about Exchange Server next.