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

Re: Remove items from source control without deleting them

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 16 Jul 2009 20:30:24 +0100

On Thu, Jul 16, 2009 at 02:24:20PM -0400, Christopher Clarke wrote:
>>> Search the 'net and you will find a lot of other people who have the
>>> same request.
>>
>> Links, please (you seem to have already found them, why duplicate the effort?).
>
> oic, duplicating effort is bad for you, but ok for my team? ;-)
>
> http://www.google.com/search?q=svn+remove+without+deleting+local

For me (I've been told google results tend to vary), that's the other
thread on this list you already pointed to, this thread on this list,
and one or two forum threads to which the answer was --keep-local.

But anyway:

I believe that there are good reasons for unversioning items in
all working copies without actually deleting the items from disk.
That's not what I'm concerned about.

What I am concerned about is this:

- Subversion calls working copies "working copies" for a reason.
  You only work with them. They should not be primary sources
  of your data. If you are struck with horror at the thought of
  losing everybody's working copies over night, you are not using
  Subversion as intended. Let alone the thought of losing a single
  file from a working copy which you told Subversion is no longer
  required.
  I could run rm -rf ~/svn right now and I not lose a single line of
  code I've been working on. It would just take some time to let the
  build script run again to compile fresh Subversion binaries.
  And maybe check the offsite backup for old patches which weren't
  committed yet. That's the intended use case.

- Who has time to design and implement the feature you are proposing?

- Why aren't the various existing solutions which have already
  been proposed enough, really?

  Again, the solutions are:

  a) Everyone backs item up, updates (item gets deleted), everyone
     copies item back. Works for existing working copies, fresh
     checkouts now miss the item (if that's OK, well, then why not.
     I still don't get why you consider this OK though).

  b) Make sure the item is properly created as part of the build process
     so that it does not matter whether it is being deleted or not.
     Then svn delete the item, everyone else updates, rebuilds, done.
     This is the one from Subversion's FAQ.
     http://subversion.tigris.org/faq.html#ignore-commit

  c) Do the same as above but remove the item from the repository
     history completely via dump, filter, load. Everyone has to get
     new working copies, checkout, rebuild, done. You also get some
     disk space back on the repository server.

I don't see why you insist on solving the problem by having a
new feature added to Subversion. This new feature will not solve
the problem for you right now. You will have to use one of the above
solutions right now with the Subversion install you have, anyway.
Unless you want to hibernate until the feature is implemented.
While at it, why not fix the problem in way b) which will make
sure you'll never run into it again? After this, do you think
you'll still need this new feature?

Well, I hope you'll find a solution you're happy with eventually,
despite all the scepticism you've received on this list.

Stefan
Received on 2009-07-16 21:31:32 CEST

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