[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs remove: removing files not locally?

From: Eric Siegerman
Subject: Re: cvs remove: removing files not locally?
Date: Fri, 3 May 2002 12:52:41 -0400
User-agent: Mutt/1.2.5i

On Thu, May 02, 2002 at 06:25:54PM +0200, Stefan Bertels wrote:
> Case: I check in a file by accident and want it removed from the
> repository. But I need the file. Think of it as per-user options regarding
> to a project.
> When I call remove the local file will be removed at my machine now and at
> all other users machines at the next update.

No.  You "cvs remove" the file and commit.  When other users
update, they'll see messages like:
        cvs update: conflict: foo is modified but no longer in the repository
        C foo

> I know that this will probably not be easy to solve - my thoughts:
> a) _every_ user has to backup the file for himself,
>    one user removes it from the repository,
>    all users restore the file (now a noncvs file)

This is the right idea.  What the user should do is:
        $ mv foo
        $ cvs update
        cvs update: warning: foo is not (any longer) pertinent
        $ mv foo

> b) I remove the file from the repository (e.g. directly),
>    _every_ user has to modify his CVS/Entries (remove the line)

Don't go there!

> Both variants are critical because if they don't update the file or they
> don't remove it from CVS/Entries before updating the next time, cvs will
> delete the file.

This is not a cause for concern.  There are two cases:
  - If the user's copy of the file is different from the one that
    was accidentally committed (i.e. they have settings that
    should not be lost), CVS will not silently remove it, but
    will report the conflict as shown above.  This will remind
    the user what to do -- and if the user does nothing, CVS will
    just keep complaining until they do.

  - If the user's copy of the file happens to be identical to the
    one in the repo, CVS *will* remove it.  But because it was
    identical, no harm has been done; it's easy enough for the
    user to get it back:
        cvs update -p -rXXX foo >foo
    where XXX names the second-to-last revision, i.e. the
    revision *just before* the "dead" one.

N.B.: I've tested this with CVS 1.11.1p1.  Older versions might
delete the sandbox file even though there's a conflict; if so,
upgrade CVS!!!


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
        - Paul Schneider-Esleben

reply via email to

[Prev in Thread] Current Thread [Next in Thread]