On Mon, Aug 22, 2011 at 10:32 AM, 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 > 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/
