You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2011/11/01 13:00:01 UTC
RFC: Ignoring conflict artifacts
Stefan2 asks how to ignore the *.{merge-left,merge-right,mine} files
when presenting a list of 'svn add' candidates.
On IRC his solution is to loop through `svn info | grep
'^Conflict.*File: '` in the directory. (The alternative was to strip
the extension(s) and `svn info` that.) But we shouldn't really ask API
consumers to do that...
So, RFC:
Subversion should treat the conflict files (the files that occur as
values of the dirent abspath members of svn_wc_conflict_description2_t)
as ignored files --- as if they were matched by an svn:ignore property
or a global-ignores setting. The existing APIs would keep their current
behaviour of reporting such files as unversioned files. (Presumably
that means adding a new status enum value and coalescing them into
'I'gnored in subversion/svn/status.c and in the API backwards
compatibility wrappers.) It would still be possible to 'svn add' such
files, just like it's possible to add ignored files today.
Alternatively, it is suggested to teach svn_wc_add() (and friends?) to
skip such files (with notification) unless --force is passed (i.e., an
opt-in feature --- which of course the backward compatibility wrappers
will enable).
Makes sense?
Re: RFC: Ignoring conflict artifacts
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/01/2011 08:31 AM, Daniel Shahaf wrote:
> On Tuesday, November 01, 2011 8:18 AM, "C. Michael Pilato" <cm...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: Ignoring conflict artifacts
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Tuesday, November 01, 2011 8:18 AM, "C. Michael Pilato" <cm...@collab.net> wrote:
> On 11/01/2011 08:00 AM, Daniel Shahaf wrote:
> > Stefan2 asks how to ignore the *.{merge-left,merge-right,mine} files
> > when presenting a list of 'svn add' candidates.
> >
> > On IRC his solution is to loop through `svn info | grep
> > '^Conflict.*File: '` in the directory. (The alternative was to strip
> > the extension(s) and `svn info` that.) But we shouldn't really ask API
> > consumers to do that...
> >
> > So, RFC:
> >
> > Subversion should treat the conflict files (the files that occur as
> > values of the dirent abspath members of svn_wc_conflict_description2_t)
> > as ignored files --- as if they were matched by an svn:ignore property
> > or a global-ignores setting. The existing APIs would keep their current
> > behaviour of reporting such files as unversioned files. (Presumably
> > that means adding a new status enum value and coalescing them into
> > 'I'gnored in subversion/svn/status.c and in the API backwards
> > compatibility wrappers.) It would still be possible to 'svn add' such
> > files, just like it's possible to add ignored files today.
> >
> > Alternatively, it is suggested to teach svn_wc_add() (and friends?) to
> > skip such files (with notification) unless --force is passed (i.e., an
> > opt-in feature --- which of course the backward compatibility wrappers
> > will enable).
> >
> > Makes sense?
>
> 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.
Re: RFC: Ignoring conflict artifacts
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/01/2011 08:00 AM, Daniel Shahaf wrote:
> Stefan2 asks how to ignore the *.{merge-left,merge-right,mine} files
> when presenting a list of 'svn add' candidates.
>
> On IRC his solution is to loop through `svn info | grep
> '^Conflict.*File: '` in the directory. (The alternative was to strip
> the extension(s) and `svn info` that.) But we shouldn't really ask API
> consumers to do that...
>
> So, RFC:
>
> Subversion should treat the conflict files (the files that occur as
> values of the dirent abspath members of svn_wc_conflict_description2_t)
> as ignored files --- as if they were matched by an svn:ignore property
> or a global-ignores setting. The existing APIs would keep their current
> behaviour of reporting such files as unversioned files. (Presumably
> that means adding a new status enum value and coalescing them into
> 'I'gnored in subversion/svn/status.c and in the API backwards
> compatibility wrappers.) It would still be possible to 'svn add' such
> files, just like it's possible to add ignored files today.
>
> Alternatively, it is suggested to teach svn_wc_add() (and friends?) to
> skip such files (with notification) unless --force is passed (i.e., an
> opt-in feature --- which of course the backward compatibility wrappers
> will enable).
>
> Makes sense?
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.
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. Besides, those
reject files shouldn't be lying about anyway if the recommended resolution
steps have been taken, right?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand