bug#37189: 25.4.1: vc-hg-ignore implementation is missing

[Dmitry Gutov]

On 22.02.2020 0:22, Wolfgang Scherer wrote:
> Both use cases are important for casual users of a VC. Before this
> research, I did not know anything about SVN, SRC, Bzr, Mtn. Ignore file
> support in 'vc' as a distilled experience cache does come in handy,
> even for experienced users. Especially, if escaping/anchoring is
> implemented.

Escaping/anchoring can be added in the next step of the "series of 
ad-hoc patches".

> I think that is the best way to proceed. The correct implementation is
> definitely non-trivial and should not be made in a series of adhoc
> patches.

Let's try to discuss this one first anyway.

> RCS, SCCS do not have ignore files, so they should error out. SRC has
> ignore files similar to CVS and SVN.

They will fail anyway because they implement neither 'find-ignore-file' 
nor the 'ignore' backend actions.

> Do not forget that CVS and SVN
> have functions vc-cvs-ignore and vc-svn-ignore, which are called
> *instead*  of vc-default-ignore. I.e. The changes to vc-default-ignore
> do not affect those VCs. For the invocation of find-ignore-file in
> vc-ignore, see below.

I think the patch is compatible with those. At least with the SVN one 
(vc-cvs-ignore might need a little work).

Have you tried this patch with SVN? Is there a particular scenario where 
it fails?

> > Roughly and handwavy, we can take this case to mean "use default-directory".
> Unfortunately not. If the file or pattern to be ignored is in a
> subdirectory of default-directory, the DIRECTORY argument must reflect
> this for CVS, SVN, SRC.

vc-svn-ignore looks like it can handle either calling convention.

> I apologize for introducing ewoc into vc-dir-mode. Meanwhile I have
> discovered vc-deduce-fileset, which does all the hard work for
> preparing a fileset in vc-dir-mode, dired-mode and other
> modes. vc-deduce-fileset delivers a backend and absolute file names,
> not relative file names.

Please submit a patch fixing that whenever you have the time.

> I think introducing relative file names in
> function APIs is the wrong way to go. However, as a preliminary
> solution, it does suffice.

I think it's just fine if the function is supposed to receive an *ignore 
pattern*, and not a simple file name.