On Mon, Aug 22, 2011 at 10:32 AM, 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
> clearly mark held-back local mods in 'svn status' (e.g. 'H'); particularly
> important for merge situations.
>
> In my vision, 'svn:hold' would be the exception, in the scale of one
> build.conf type of file per huge project tree. But that's up to the users.
> Which is exactly the point!
>
> (See notes/hold for more points.)
>
I really do not know where I stand on this. If you had asked me before you
started if it would be good to have a feature where certain local files
could be ignored by commit I would have said Yes. Now that you have started
working on it, and some more thought has gone into it I am less sure. I do
worry about the implications of a feature like this in terms of what the
behavior should be on other commands.
Maybe a different implementation could make a difference? Just thinking out
loud ....
What if SVN had a feature like TortoiseSVN where any file in a specifically
named changelist was automatically ignored on commit unless that specific
changelist is named ($ svn ci -cl ignored-files ) We could probably make
commands like status and diff automatically ignore this changelist too.
Perhaps we could then go a step farther with this feature by automatically
adding files with a special property like svn:hold to this changelist when
they are checked out?
Maybe if svn merge updates a file with this property it removes it from the
changelist so that it will be in the list of files to commit? svn commit
could add the file back to the changelist, just as a commit on a locked file
puts the read-only attribute back on the file?
An approach like this might be more complicated to implement but it avoids
adding new options, and I *think* it makes the behavior on other commands
clearer. Since TortoiseSVN has had this feature for a long time, it would
be interesting to know what kind of edge cases people have raised with the
feature. Has anyone asked that these files not be updated or merged?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-22 16:45:33 CEST