On Fri, May 7, 2010 at 10:16 AM, Eric Blake <ebl...@redhat.com> wrote: > On 05/07/2010 09:02 AM, Peng Yu wrote: >> Suppose I need to modify one primary file slightly to do something a >> little bit different. But I still need to do the original job, >> therefore I need to keep it the original M files. I can copy the whole >> directory and then modify one file in the newly copied N files. But >> I'll lose track of which file has been changed later on, which is >> important to me. > > Consider using a version control system. Track the contents of your > directory under your favorite VCS, like git, and then you can use > version control commands to generate the delta for both primary and > secondary files across any state that you committed.
I can't use version control for 1. I need to frequently change file names. 2. Both primary and secondary files could be of hundred of MB or even GB. > Or, for a one-shot solution, you could use a BSD union mount, where the > difference between the mount overlay and the original directory shows > exactly what was modified. The problem is that if I have many directories that form a complex copying graph. It is not possible to keep track of all the possible lineages. Also, I need to avoid change multiple copies of the same file. > But overloading bash's > and >> operators is not possible. Is it because the underlying library that used in bash doesn't support the semantic of symbolic link that I propose? Or it is because of the OS? Is it possible to modify source code of bash to change the semantics of symbolic link. -- Regards, Peng
