[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A couple of problems with svn rm.

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2001-12-20 17:01:00 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.