On Fri, Jul 17, 2009 at 6:18 AM, Christopher Clarke
<tigris.org_at_fuscata.com>wrote:
> 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
Is it really that hard to word the following email?
"Hey all, as of rX, the file foo.bat will be deleted. Copy the version
attached to this email into your environment and all will be good. Cheers,
Y".
>
> 2) some users will not follow directions
That's their problem - if they don't follow directions, things break. It
isn't uncommon in the Windows world.
>
> 3) some users are machines, not people
Then these will have to be done manually.
>
> 4) takes a lot of everyone's time
>
Turning the point around - what's the harm if these files are under version
control? If it's causing so much grief to remove it from the repository (but
leaving it in the repository), why can it not stay in the repository? If it
isn't meant to be modified, then put in a pre-commit hook preventing it.
> > 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).
>
> 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.
>
Are these file(s) used only on a development environment?
>
> > 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
>
> 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.)
So delete the family photos (which probably should not be in the repository
to begin with)? Everything is still in the repository, so nothing is lost.
> 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).
Okay, but if you then delete those files from the repository, why should
they remain in EVERY working copy at that revision?
Cheers,
Daniel B.
<snipped />
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2372507
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-20 08:14:29 CEST