Greg Stein wrote on Mon, Aug 22, 2011 at 14:46:16 -0400:
> On Mon, Aug 22, 2011 at 10:32, Neels J Hofmeyr <neels_at_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.
Received on 2011-08-22 21:35:41 CEST