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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-11-01 13:18:44 CET