On 07/16/2009 03:30 PM, Stefan Sperling wrote:
> 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.
Good, thanks, glad we can move past that. :-)
> 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...
Not sure why this is relevant. I'm not worried about losing data, just
don't want to make everyone on the team spend a lot of time just to take
something out of version control.
> - Who has time to design and implement the feature you are proposing?
Oh, you mean you weren't sitting there, checking your email, waiting for
a new feature request to come in so you'd have something to work on?
That could be a problem, but doesn't mean it shouldn't be added to the
list of things that might get done some day, by somebody, maybe, if the
resources are there.
> - 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,
1) hard to explain to everyone how to do this
2) some users will not follow directions
3) some users are machines, not people
4) takes a lot of everyone's time
> checkouts now miss the item (if that's OK, well, then why not.
> I still don't get why you consider this OK though).
Setting up a local dev environment involves many steps in addition to
svn checkout. Adding 1 more step for the rare case when we add someone
to the team is not a big deal, is expected, and only affects one person
at a time.
> 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.
Works for some situations. Does not work for some e.g. 1) we decide to
take images dir out of svn. (It was a good idea when it had 50kb of
icons, but now it has 50gb of family photos.) 2) 3-rd party software has
decided to provide a GUI for users to change settings that are stored in
config files. A terrible idea, but I have no control over that. 3) I
made a mistake and added + committed something that I should have
ignored (b/c my GUI is so fast and easy and I got drunk and "OK" happy).
4) Someone didn't read the FAQ before setting up the repos and/or for
whatever other reason decided to "unadd" something that someone added
before. 5) etc.
> 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.
Again, too much work for the users and for me.
> 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?
To me, this logic goes against the principals of FOSS. I want to see the
software improve. If I thought I was the only one who wants this
feature, I would not have started this discussion. You said yourself
that you see the need for this feature.
If I hadn't already solved the latest problem caused by this missing
feature, I'd still be working on it rather than arguing with you. :-)
> Well, I hope you'll find a solution you're happy with eventually,
> despite all the scepticism you've received on this list.
Thanks. I was hoping for skepticism, to see if any there was a
convincing reason not to add a feature request to the bug tracker, as
directed on tigris.org.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-16 22:19:17 CEST