creates a patch file which consists of instruction for As the title says, Can't this be done using |
||||
|
|
|
Diffs can be more complicated than just comparing one file versus another. The can compare entire directory hierarchies. Consider the example that I want fix a bug in GCC. My change adds a line or two in 4 or 5 files and deletes a handful of lines in those and other files. If I want to communicate these changes to someone, potentially for inclusion into GCC my options are
Copying the entire source tree doesn't make sense, but what about the other two options, which gets at the core of your question. Now consider that someone else also worked on the same file as I did and we both give our changes to someone. How will this person know what we've done and if the changes are compatible (different parts of the file) or conflict (same lines of the file)? He will diff them! The diff can tell him how the files differ from each other and from the unmodified source file. If the diff is what is needed, it just makes more sense to just send the diff in the first place. A diff can also contain changes from more than one file, so while I edited 9 files in total, I can provide a single diff file to describe those changes. Diffs can also be used to provide history. What if a change three months ago caused a bug I only discovered today. If I can narrow down when the bug was introduced and can isolate it to a specific change, I can use the diff to "undo" or revert the change. This is not something I could as easily do if I were only copying files around. This all ties into source version control where programs like In summary, yes, |
|||||||||
|
|
When you get a patch you can often (that is unless you have made changes to the exact same lines) apply the patch to a set of files that you have changed yourself as well. The patch has information about the old and the new state of the files. If you get a copied file you don't know what the original was (the old state) and you cannot apply the differences to a file (or set of files) that you have changed as well without great difficulty. So for sets of source files it is not the space preservation that is of major concern, it is the before-after information. Before (unified) diffs this was often done with instructions for editors (insert a line after X, delete line Y), but that would only work if you knew the state these instruction started from. Thus having the same problem as your "solution" with just copying. |
|||||
|
|
If you are using diff, you can see what exactly has changed, so using diff/patch is a way to prevent someone from slipping unwanted changes in the file. |
|||
|
|
|
The changes made to the files are usually much smaller than the files being changed. This means storing a diff can save you a lot of space. When But it also means you can reapply a diff to the original file, even if that file has changed in other ways. The patch utility will do that for you and tell you when there are problems. This is in fact the most important reason to work with diffs in software development. When a change has been made (usually to more than one file), it can be saved as a diff: the result is called a change set or patch. If all is well, the patch is not just some arbitrary change, but implements some kind of functional change - e.g. a bug fix or a new feature. Meanwhile, a different change can be made, possibly by a different developer, even in a different location. If the changes weren't made to the same parts of the same files, they can then be applied independently. So the developers can send each other their patches for testing. A whole set of patches can build up that represents possible changes; some of these may ultimately be rejected, the rest will be integrated into the system. So working with diffs allows concurrent development. You no longer have to work on one change at a time. Modern distributed version control systems are a continuation of this way of working. |
||||
|
|
