Greg Stein wrote on Mon, Aug 22, 2011 at 14:46:16 -0400: > On Mon, Aug 22, 2011 at 10:32, Neels J Hofmeyr <ne...@elego.de> wrote: > >... > > Greg/anyone, do you have any more arguments against svn:hold except "people > > will trip over a prop they read the documentation of and set up themselves > > before it had any effect" -- because I don't think that's a real problem. > > They would have tripped over 'svn:ignore', 'svn:externals' and > > 'svn:keywords' long before tripping over 'svn:hold'. BTW, my intention is to > > svn:ignore affects status and add. If a file is *already* > version-controlled, then it has no impact. > > svn:externals is a way to stitch together multiple working copies of > version-controlled nodes. > > svn:keywords merely affects expansion in a working copy. There is no > operational impact. > > ... but svn:hold? That alters the very operation of a > version-controlled file. Now, all of a sudden... it does not > participate in a commit. If somebody set the value *locally*, then I > say "fine. they did it. they should know". But this thing can go into > the repository, and then just appear in my working copy. And out of > nowhere, my files don't commit like they should.
Same thing if someone else sets svn:ignore and you have a local addition you hadn't told svn about yet. How would you explain that behaviour? Perhaps by saying Alice should have warned Bob that she'd set svn:ignore? And however you explain it --- why doesn't the same explanation apply to svn:hold? === Random thought: We could have 'svn update' output warn when such special properties (svn:ignore, svn:add, svn:server-dictated-hook, svn:repository- dictated-config) are added by an update.
