Re: meld filename scans entire tree

[Kai Willadsen <kai willadsen gmail com>]

On 26 April 2010 11:27, Grant Edwards <grant b edwards gmail com> wrote:
> On 2010-04-24, Kai Willadsen <kai willadsen gmail com> wrote:
>
>>> On a related topic (I think), is there anyway to avoid the complete
>>> re-scan after reverting or commiting a single file?  It really mucks
>>> up workflow if after every operation you have to wait a minute or two
>>> for meld to rescan a large progje tree for no reason.
>>
>> Not currently, no. Meld is overly conservative, and assumes that it
>> needs to rescan the tree after any VC operation.
>
> Are there cases where commiting or reverting file X changes the status
> of a file other than X?

I suspect there are cases in which it happens for some VCs. You could
do pretty evil things in a post-commit hook if you tried hard enough,
I think.

However, ignoring corner cases... if we had a VC-backend-specific
whitelist of things guaranteed not to change anything other than file
X, then it would be relatively easy to go through and whitelist
appropriate operations. I can't see myself getting time to work on
this soon however.

>> There is the start of some refresh-related code in VcView, but
>> judging by some FIXMEs and the lack of VC-specific information, it's
>> a fair way from functional.
>
> OK, I guess meld just isn't work for that use case: reviewing each of
> a set of changed file and then commiting or reverting the file.

Others may have different ideas, but I don't think Meld's focus is on
being a full VC interface. I personally use it as a tool to complement
command-line VC usage. There's no reason we *couldn't* be a more
complete VC interface, it's just not something that I'll personally
spend a lot of time on, given the list of other things to be done.

cheers,
Kai