Concerning Re: "svn update" fails to remove fo
Les Mikesell wrote on 21 Nov 2009, 11:45, at least in part:
> Jan Hendrik wrote:
> > Concerning Re: "svn update" fails to remove fo
> > Ryan Schmidt wrote on 20 Nov 2009, 17:06, at least in part:
> >
> >> On Nov 20, 2009, at 15:01, Jan Hendrik wrote:
> >>
> >>> I should say this is a very dangerous approach. While you may be
> >>> certain that none of the possibly ignored files (how about ignored
> >>> subfolders?) in a folder of your working copy you are about to
> >>> remove is of any value for you, another developer may have ignored
> >>> files of value for him which such a switch would remove on update
> >>> just the same, without his knowledge or even consent.
> >>>
> >>> I can see the upside for e.g. editor-generated backup files, but I
> >>> also use ignore patterns for script drafts, ideas files, one-time
> >>> copies of versioned scripts customized for specific tasks etc.
> >>> etc.
> >>>
> >>> I wouldn't want any other person with commit rights to tamper with
> >>> these.
> >> I think the suggestion was to add a switch to "svn update"; thus,
> >> the person doing the update is in control of whether files in their
> >> working copy will disappear or not. If you don't want this
> >> behavior, you wouldn't use this switch on your working copy.
> >
> > Shows how different understanding can be. Mine was that in the
> > first place the OP suggested a switch to svn rm to get the whole
> > folder out of his hair at once. But you're right, it's "update" in
> > the subject. The suggested switch:
> >
> >>> --dont-preserve-ignored : do not preserve ignored files when
> >>> (re)moving folders
> > ^^^^^^^^^^
> >
> > had mislead me.
> >
> > Anyway, my objection stands. No one in his mind would use such a
> > switch except when being 200% sure one has no ignored files
> > anywhere. For on update one will never know for certain what
> > exactly happens (except if one scrutinizes the logs first and then
> > updates to revX, never HEAD).
> >
> > A switch to svn remove would make true sense only if a flag
> > (property) is added to remove the folder on updates of any other
> > working copies no matter what ignored/unversioned files are in it.
>
> Can't you already get this effect, if you want it, by making sure you
> have committed all your modified files, deleting your working copy,
> and checking it out again? Seems kind of drastic, but so does asking
> update to remove something not under subversion's control.
Removing stuff SVN had no business with in the first place seems
bad practice indeed.
As we are still with 15.7 I am not sure if ver. 1.6.x not already does
this, but far better than any switch or silent removal would be some
sort of conflict error if SVN can't remove a folder on update because
of remaining ignored files in it. That way the user becomes aware
of the situation and can deal with it (unlike my experience in such
cases these folders live on until chance notice). Obviously the
original poster wants no awareness nor deal manually with this
kind of stuff, so this suggestion is not what he wants.
JH
---------------------------------------
Freedom quote:
Is life so dear, or peace so sweet, as to be purchased
at the price of chains or slavery? Forbid it, Almighty God!
I know not what course others may take but as for me;
give me liberty or give me death!
-- Patrick Henry, 1775
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2422904
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-21 21:51:58 CET