Hot answers tagged

9

Just as you can create a patch for a text (source) file, you can create a patch for a binary file as well. You are effectively just noting what changed between two files (that's called delta encoding). For example, if the app contains many resources, then those don't usually change for smaller updates, and only the executable code itself needs to be ...


7

This is a very hard question, and only a specialised lawyer will be able to give you an answer. I will just address the technical aspect of your question. Technical solution of your problem The easiest technical solution to your problem is to use another patch format. The patch and diff utilities support several formats, and an especially interesting one ...


5

The Patience Diff algorithm is designed to address this, insofar as it is possible to do so with unannotated text. From that article: [Patience Diff] only considers lines that are (a) common to both files, and (b) appear only once in each file. This means that most lines containing a single brace or a new line are ignored, but distinctive lines like a ...


5

Simplicity. Incremental updates have the same problems as incremental backups; you must apply all of the increments in order from the last complete installation. It becomes impractical to do this forever; eventually everyone will have to get a complete update. Otherwise, you wind up selling a program that requires n incremental updates to get it current (...


4

Sometimes you can't get away with a small change. You might need to forgo GitHub's code review tools and use Plain Old Git: $ git remote add somebody https://github.com/somebody/repo.git $ git fetch somebody $ git diff --name-only development somebody/topic_branch # shows list of files that were touched $ git diff --name-status development somebody/...


4

This is actually one of the benefits of introducing code reviews in your organization: getting people to make small, incremental changes. Just wait until the guy that made that huge commit has to review a similarly sized commit of yours. Other, more constructive ways of getting to the same result without starting a "commit war", could be: setting a soft ...


3

Because usually, diffs are created to be able to compare any file, not only hierarchical-organized source code or data. Because in order to obtain a tree from a source code, one needs to parse it first. Reading lines - every app can do that. Being able to parse C++, Ada, Java, COBOL, Haskell and hundreds of programming languages and non-programming languages ...


3

A working solution is to put a soft upper limit on how large merges you accept, but changes have to be reviewed as some point. If you don't have much experience with source code reviews yet, you could start out recording metrics of the reviews (too): Merge/commit size Issues resolved Errors introduced Review reports Reviewer Time used Volume of comments ...


3

This is not going to be something that can easily be answered. Typically, I would recommend "staying clear" of the issue (don't publicly distribute the patch). You have (as far as I can tell) two real questions that need answering. First, are the little snippits of code in a diff in violation of copyright laws if publicly distributed. I would tend to lean ...


2

You should update your version of the main branch against the latest version of the main branch, pulling in changes that have occurred since you branched off for your feature branch. Once this is done you can then compare your differences alone. Example using git: First git rebase (or git merge but I prefer git rebasein case of code conflicts) the feature ...


2

There is no industry standard. The diff-and-patch workflow originated in the mid-80s in the context of open-source Unix development. You could send diffs around via email and then apply that patch to your local code. This was influential in the development of version control systems like Git. Other ecosystems have entirely different conventions. Also, ...


2

I don't know how SE does it, but the most straight-forward way to approach this would be (IMHO): Store the initial post in a posts table When someone makes a change, create a diff between the new post and the original post (or previous version, if it has been edited before). Look for a text-diff library, or google for a 'Longest Common Subsequence' ...


2

There is more than one way to do it, and there are probably practical constraints to doing it that you haven't mentioned. Given the small information, here's how I would do it. Let's start with some assumptions: This database is in moderately heavy usage, adding some load is acceptable but placing a heavy load on the system is not. You care that you that ...


1

They've directed that I send every change as a whole file. Since we both make changes to the code, they then need to manually find my changes and merge them (or not). I understand that this pain is now theirs, but if they choose to not merge because they don't see a change, I am directly affected (and troubleshooting is difficult). Is there a better way I ...


1

It appears that perhaps all you have as other metadata is the record count in each database? Using just that, perhaps you can, on each round of updates from the external sources, see if the record counts diverge (more than they already are). If they do, then at least you have a suspect record (update) set that should be closely examined in each database to ...


1

A tool like Semantic Merge which understands the language semantics by parsing the code will work in this case.


1

You might do in a vimdiff-like version: Step 1: identifying added, deleted and modified sentences. Step 2: for each modified sentence, locate the first and the last changed words, and cut anything not between these two words. If you need to keep coherent more grammar structure, look at the internals of http://www.languagetool.org/ or another shown on ...


1

Well, in the first place I could argue that creating a new procedure1 that does what procedure2 did, with the same signature, is begging for trouble. Even were procedure1 to be the most natural name for the new procedure, you ought to differentiate it at the name level, to prevent confusion down the line. On a change of this import, the procedure1 name ...


1

Here are some options you might want to consider. Some diff tools have an option to input regular expressions as part of the comparison process and some, I believe, have active people in the forums tweaking the expressions for a given language. Write your own diff tool that compares the syntax and tweak the code. I started this but you spend more time ...


Only top voted, non community-wiki answers of a minimum length are eligible