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