On Mon, Aug 22, 2011 at 12:51 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> On 08/22/2011 04:45 PM, Mark Phippard wrote: > > On Mon, Aug 22, 2011 at 10:32 AM, Neels J Hofmeyr <ne...@elego.de > > <mailto: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. > > Hi Mark, > > you first express concerns about implications on other commands, and then > you propose the exact same feature and implications using changelists? Come > on :) > > > > > 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? > > I thought about this too, actually, and came to this conclusion: it just > inflates the whole implementation. Nothing more. The exact same thing can > be > achieved with *just* a property, without having to "rape" changelists: the > changes to changelists would be: introduce special treatment of changelists > that have a specific name (-1). Introduce reversable changelists (+1) but > only do it implicitly, if it has one certain name (-1). *After* you did > this, you put into life a property (where we already have a reserved > namespace and long history for storing svn-internals), and instead of > querying the prop directly, you have changelists inserted in the chain. I'm > -1 to that. > I think there is a difference. By using a combination of svn:hold and changelists the tool can do work for the user. Merge is the best example (it might be the only example). When you do a merge, we could automatically remove a file from the ignore changelist so that it would be committed by default and not require the user to add a special option to their commit. Commit could then put the file back on to the ignore list. I do not think we have to use changelists to accomplish this. I was just using that as an example. Using changelists does have a benefit that it already has a lot of UI. Wow, I didn't think I'd have to argue this much :) > I still don't see how 'svn:hold' is problematic to include in 1.8. > More cons? > I would not have expected this either. But I have to say that I am not convinced that the benefits of this feature outweigh the negatives. Right now, I think the negatives far exceed the positives. I think this feature could actually wind up being very confusing to users. -- Thanks Mark Phippard http://markphip.blogspot.com/
