On 26 April 2010 11:27, Grant Edwards <[email protected]> wrote: > On 2010-04-24, Kai Willadsen <[email protected]> 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 _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
