On Mon, Aug 22, 2011 at 7:19 PM, Neels J Hofmeyr <neels_at_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/
Received on 2011-08-23 02:19:43 CEST