> > 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.
> ...
> 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.
Ok, so what I hear you saying is that I need to tag the vendor branch
both before AND after doing the import, then give those two tags to an
update -j. (something else that I didn't see in the manual -- I had
thought that the vendor branch support was magic).
> 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.
>
> > 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
[ ahh -- now I understand what you were saying -- foo.c is modified,
but "cvs rm" isn't a patch against /dev/null + remove if empty, but just
a remove. ]
> 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.
Here I have a suggestion that will fix this.
The idea of "File Removed" should be changed to "file is atomically both
made equal to /dev/null and removed".
If I have a file on a branch, that has been removed on another branch,
then when these are brought into sync with each other (regardless of
which was on the trunk or common branch first), then the "removed" file
should just be considered "/dev/null", the modified file will differ in
that all the lines that are new in it are not removed (they weren't in
the original, so they could not have been removed when the file was
deleted), so the resulting merge will be a non-empty set of conflicts
(the added lines), and the resulting "has conflicts' file will just be
the changes.
The result in this case: The file being removed on the vendor branch is
the same as all the original vendor lines being removed; all that is
left is your lines, all of which are in conflict with an empty file.
And, since this is (at least, this is what I'm proposing here) the
meaning of a removed file, you CAN just mark it as removed, and it will
not be brought back by another cvs update.
> 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..... ;-)
Now this worries me. Are you saying that this can happen on non-vendor
branch changes if a file is modified on a branch (or trunk), and deleted
on the trunk (or branch), and then the changes are merged with 'cvs
update -A -jbranch'?
Michael
