[ On Wednesday, May 10, 2000 at 12:00:56 (-0500), Michael Gersten wrote: ]
> Subject: Re: bug in import?
>
> Now I'm confused. How is it a feature?
>
> Assume that I want to be able to say "This is the newest source code
> from the vendor. This file foo.m is now gone, and not used. No changes
> have been made to foo.m on my system; it is still version 1.1.1.1; it is
> not used anymore. I want it to disapear from future checkouts". How do I
> do that?
That's what it's doing -- "dead" files are removed files. However it
doesn't really "automatically" make them go away -- you have to do that
with a merge and a commit in order for it to take effect. All that's
"automatic" is the fact that CVS can (usually) detect their
disappearance and do the "cvs rm" for you.
Unfortunately if there were no obvious conflicts CVS won't suggest a
merge, and even more unfortunately the suggested merge command given
when there are conflicts won't always work either.
You need to do the merge regardless of whether there were conflicts
detected on the merge, and you need to explictly specify the previous
and current vendor branch tags (as opposed to what "cvs import" might
suggest if there is a conflict). This information should be in the
manual by now, but I see that it isn't.
Here's an example of what will happen:
$ cd testi # working directory where module is checked out....
$ cvs update -j TESTI-1 -j TESTI-2 .
cvs update: Updating .
cvs update: scheduling foo.c for removal
Now you can commit all the files marked for removal by the merge and
your local working copy/copies (after a "cvs update" in any directory
where you did not do the above commit) will be again in sync with the
vendor release.
Of course you might also have to merge any vendor changes that conflict
with local changes, but that'll be obvious after the merge has run... ;-)
Even worse it seems as though the merge, even when done with the correct
and explicit release tags as above, doesn't always spot removed files.
I've been unable as yet to come up with a concrete test case so that the
bug can be explored and hopefully fixed, but it does happen to me quite
often in the NetBSD "pkgsrc" module which I track locally.
> And, if foo.m is at 1.2, and the new import of 1.1.1.2 is a removal,
> what would it take to get it marked as a conflict, with the new version
> being empty (in other words, showing the merge/conflict file as only
> having my modifications, so I can move the added routines to another
> file where they (now) properly belong)?
Yes, if you've locally modified a removed file it will be marked as
having a conflict, but only as you do the merge, and only if the change
was not yet commited and is in the directory where you do the merge. In
this example I've modified both foo.c and tbin.c, but only committed the
local change to foo.c. I then removed both foo.c and tbin.c from the
second vendor import. Here's what the merge does:
$ cvs update -j TESTI-1 -j TESTI-2 .
cvs update: Updating .
cvs update: scheduling foo.c for removal
M tbin.c
cvs update: file tbin.c is locally modified, but has been removed in revision
TESTI-2
CVS probably should do something the same for foo.c as it does for
tbin.c, but it's hard to decide exactly what to do. There's currently
no "state" that a file in a working directory can be in that'll indicate
that there are changes on the current branch that will be "lost" when
the pending removal is committed. I suppose the merge could be done by
trying to patch the local file with a diff against /dev/null, which of
course will result in a real conflict. Unfortunately then you couldn't
mark the file as removed and anyone not paying attention would simply
think the file had accidentally be removed from the local working
directory, especially since a subsequent "cvs update" will just
resurrect the (old incorrect version of the) file again.
So in the mean time you have to be careful to check the "cvs log" before
committing the removals detected by the merge to see if any local
changes might be lost. Of course you should be so careful all the time
anyway, and if your creating local releases that include your local
changes then you'd hopefully detect missing local changes elsewhere
during the release process too..... ;-)
It is quite possible that you'll have to re-do your changes in another
file if in fact what the vendor did was to rename the file, or include
its contents in some other file, or whatever. In the all other general
cases it's highly unlikely that any local hacks to a vendor removed file
will need to be preserved (eg. by moving them to some other file).
> What do you mean by "automated file removal"?
Yeah, well it's not really "automated" I guess, but it's a damn sight
better than it was before when you had to manually figure out which
files had disappeared between vendor releases.....
> (Incidently, I get bounces anytime I try to send to [EMAIL PROTECTED])
(Then either there's something incorrectly configured in your mailer or
DNS; or your mailer is listed in the MAPS, ORBS, or DUL, or some other,
RBL. I did a quick peek through the logs for "getasia.com" and didn't
see it anywhere so I don't know what exactly is wrong, but the bounce
message should be quite explicit about the problem.... Hmm... in this
message you sent to the list it would appear that you're trying to send
mail out directly from your dial-up connection. That is a no-no -- you
must use your provider's outgoing mail relay. By all rights UUNET
should be blocking all direct outgoing SMTP connections but they can't
because they've painted themselves into a corner by reselling their same
dial-up ports to other providers and they don't have the right
technology in place to drop IP filters in on the dial-up server port
directly.... But they do list your IP in the DUL RBL and anyone with
half a mind to block random spam and e-mail forgeries will block your
e-mail unless you send it through UUNET's outoing mail relay just as
their setup instructions tell you to do. See http://maps.vix.com/dul/)
(BTW I set the "reply-to" to the list for a reason.... ;-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
