[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 foo.save
$ cvs update
cvs update: warning: foo is not (any longer) pertinent
$ mv foo.save 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