The Hermit Hacker <scrappy@hub.org> writes:
> Odd...it was doing a 'second checkout' that screwed me, where
> i didn't think it worked...try doing 'cvs -d <> checkout -P pgsql'
> and tell me what that does...
I assume "<>" means "the same path as before", in which case this is
just doing a new checkout on top of an old one, right? I've got one
of those running now, to see what happens, but I don't see why you
would want do do this. "cvs update" is the way it's supposed to be
done, once you've got the tree checked out. I know _that_ worked.
Right now, the second "cvs checkout" is running, and there seems to be
much communication going on, but no new downloading of files I already
have. Pretty much like during the "cvs update", that is. We'll see.
Ah, yes. Here we go. This looks just like the "cvs update" pass. In
fact, it seems that a second checkout on top of an existing one turns
out to behave just like a (more proper) update from within the tree.
Done now, worked fine.
I'm starting to look forward to when the CVS source tree gets into a
buildable state again! This could be a comfortable way of keeping up
to date with the current sources. Here's hoping you find a good
solution to the s_lock.h misunderstandings soon... :-)
> And, yes, password is required...
I've found where it's stashed, now. I guess that means you only need
to supply it once, to do the initial checkout, and after that you
won't have to worry about it.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"