[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Ignoring conflict artifacts

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 01 Nov 2011 08:50:17 -0400

On 11/01/2011 08:31 AM, Daniel Shahaf wrote:
> On Tuesday, November 01, 2011 8:18 AM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
>> I think I'm okay with adding this intentional ignoring logic in the
>> command-line client (so long as it can be overridden). I'm less okay with
>> modifying our APIs to automatically ignore such files.
>>
>
> I'm suggesting the APIs ignore such files, not exclude them. That
> means the files will still be reported if the API equivalent of --no-
> ignore is passed.
>
>> It is a feature that if you wish to do so, you can 'svn add' your reject
>> files, force the resolution of your conflict, and commit so that another
>> team member can do the work of really resolving the commit.
>
> Stefan2 made the same point on IRC, and that's why I specifically wrote:
>
>>> It would still be possible to 'svn add' such files, just like it's
>>> possible to add ignored files today.
>
>> Besides, those reject files shouldn't be lying about anyway if the
>> recommended resolution steps have been taken, right?
>
> I don't think we should assume that no one ever has a use-case for not
> resolving a conflict as soon as it happens.

Obviously I wasn't suggesting that (see "It is a feature..." above). I
guess what I was trying to get at is, if you choose not to resolve your
conflicts before taking additional version control steps (such as 'svn
add'), you get what you get.

In summary: I see no pressing need to make changes *at all* in this area.
If changes are to be made, I would prefer they be limited to the
command-line client logic, leaving the APIs alone.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-11-01 13:50:52 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.