On Mon, Aug 22, 2011 at 7:19 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> > 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. > > My preceding mail elaborated on this point; the local modifications may be > considered secret, so svn should not fully-automatically commit held stuff, > but should instead complain to the user. > > > Right now, I think the negatives far exceed the positives. > > I think this feature could actually wind up being very > > confusing to users. > > I don't see it that way at all. I don't see how negatives that don't ever > appear until you even use the feature can outweigh any positives you can > get > if you choose to use the feature. I have proposed numerous solutions to all > negatives. I'm thinking: whether to use svn:hold in the repos is up to > project management. Users can still use it locally. It's always a choice. > Just because you do not have to use the features does not mean that adding them cannot lead to problems and confusions. You like to talk about the IDE use case, so let's talk about it. That is where I am coming from on this too. In Subclipse, when someone does commit we load a dialog with all of the modified files, do we show modified files with this property? If we do, and the API does not commit the file that is going to confuse users. This even assumes the Status API has some value that let's us know the modified file has this property. If we have to do secondary API calls to get this information, I'll be pissed as both a developer and user. Most likely we have to add new UI to our commit dialog that lets you toggle whether or not to show these files. Maybe we can implement it such that this UI only shows up if we detect you have some of these files, but if not then all users have to pay the price of extra "stuff" in the UI. In Subclipse we also have a Synchronize view which visualizes local and remote changes. This is another place where we will have to account for this. I am not saying the feature has no value, or even that your design approach is bad. I am just saying the issue is more complicated than I originally thought and I have been thinking out loud on the problems I see with it. I just need a basic go-ahead that the users' call for such a feature > should/is allowed to be answered. How minimal it will be is totally up for > discussion. I can offer more patches, and you can decline them. > > At this point, I want hard fact & proof if you're going to say "no". > Speaking for myself, I am not threatening a veto or anything. I am just expressing my concerns so that we can talk through and possibly improve the design. -- Thanks Mark Phippard http://markphip.blogspot.com/
