Hey Mo, Mike Pilato and I were just talking about your question
(below), and we agree with you that "svn rm" should remove the working
file when there are no local modifications. It's not like any
information is actually lost thereby, after all.
So we're proposing:
$ svn rm no-local-mods.c
==> removes no-local-mods.c, and schedules it for removal from
revision control
$ svn rm has-local-mods.c
==> leaves has-local-mods.c, but schedules it for removal from
revision control
$ svn rm --force any-file.c
==> removes any-file.c, and schedules it for removal from
revision control
Anyone think this is crazy?
-Karl and Mike
Mo DeJong <supermo@bayarea.net> writes:
> > > % svn rm bar.c
> > > D bar.c
> > > % ls
> > > bar.c foo.c
> > >
> > > Now, why is bar.c still there? Why does the client fail to remove
> > > the file?
> >
> > Update does this, I believe that's where we stand on file/dir removal.
>
> Do you mean commit does the unlink? Why would the update
> command be responsible for this? What if I don't run update? If I delete
> a bunch of files and then commit the delete, I would not expect the files
> to still be there. Is this same logic going to apply to a `svn mv` operation?
> I would not want to `svn mv` a file and have to run update before the old
> one went away. Can't we just let rm remove the file in the wc? I could
> see where we might not want to do that if there were modifications to
> the file, but in the normal case this seems strange. Ben mentioned the
> --force flag, why is that not the default for a rm operation?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006