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.
And now you're saying that it affects more than commit. Diffs? Copies?
If you limit it to *just* commits, and if the generated log message
would say something like, "The following files are being held from
commit:\nH some/path/foo \nH other/path/bar\n", then I'd be more
supportive. When somebody goes to commit, then it is very clear these
files are not participating. (and yes, showing 'H' in status is a good
thing, with the understanding it means "modified, but being held"; the
file should not show at all, if unmodified)
I think 'svn diff' should continue to show the local modifications.
And it should be copied just like any other file. And that may mean
copying with the local mods. When committing that copy, a copy will be
performed on the server, but the local mods will not reach the server
due to the svn:hold.
Cheers,
-g
Received on 2011-08-22 20:46:45 CEST