Is it possible to diff 2 files. Say version 1.0 and version 2.0 of a software. Creating a reasonably sized diff. Then diff a patch vs version 2.0 of the software which also includes diffs from version 1.0. So essentially subtract the diff of ver1 ver2 from the diff of patch ver2.
Example I want to diff a patch applied to a soft at its version 1.0 stage, but vs the version 2.0. If I do diff patch vs ver2. The diff is huge because of all the changes from ver1 to ver2. So i want to diff ver1 ver2, then subtract this diff from the diff of patch ver2.
Related
Is there any way that I can "update" svn base number after applying a patch?
For example right now my project has base revision: 860 and I want to add manually patches till revision 864 ( Head is 866). After applying those patches is there any way that I can update base revision number in order to be visible inside eclipse?
Is there a diff tool which can highlight single character edits as such, and not just show the old and new version of the whole line (i.e. the kind of diff StackExchange shows you for edits to a post)?
I'd prefer one I could use on the Linux command line as diff in git.
You can try, from git diff:
git diff --color-words=.
Which is equivalent to --word-diff=color plus (if a regex was specified) --word-diff-regex=<regex>.
That would transform this git diff:
into this one:
Images are from the section "Produce more useful diffs" of the article "30 Git CLI options you should know about" written in Sept. 2014 by Christophe Porteneuve.
At least by default, and committed version number is a single number with 1 increment. Can I specify the version number as major.minor when committing? Or there is another mechanism I overlooked?
Revision numbers are automatically incremented by every commit in the branch, and thus they are integer numbers.
When you merge another branch into the current branch, the revisions of that branch will be renamed using a dotted notation, in the format BASE.BRANCH.REV, as you can observe for example in the Bazaar project itself:
bzr log --line -n0 -r6572..6573 lp:bzr
This dotted notation has nothing to with major-minor version numbers. You can read more about this in the documentation: http://doc.bazaar.canonical.com/beta/en/user-guide/zen.html
On the other hand, you can assign tags to revision numbers, and these are designed exactly for this kind of purpose, to mark release numbers. For example in one of my projects I have the following tags:
$ bzr tags
1.1 159
1.3 188
This means that I assigned (in the past) the tag "1.1" to revision 159 and "1.3" to revision 188. The "1.1" and "1.3" are indeed intended as major-minor release numbers.
Tags work like aliases to revisions. These commands are equivalent:
bzr log -r revno:159
bzr log -r tag:1.1
(As a matter of fact Bazaar is smart enough to figure out the right even if I drop the revno: and tag: prefixes)
You can create tags using bzr tag, you can assign tags to the latest revision or any past revision. See bzr tag --help for details.
It's not a version number, not in the sense of a product's version number. It's a revision number -- you can consider it the number of changes made to your project.
We have a project in which we've been doing some work in a Branch for version 6.1. One of the changes made in the 6.1 branch (changeset 1800) was a bugfix, and someone decided it's urgent enough to merit a patch to our 6.0 production release.
Now, changes were made to the file in question both before changeset 1800 and after it. What they want is for JUST the patch to be applied to 6.0.
As per http://linux.die.net/man/1/patch, it seems that the best thing to do would be to create a diff file by comparing changeset 1800 to 1799, and then apply that diff file as a patch to 6.0. I don't even know where to begin doing this in TFS.
As a fallback plan, I can always just go through the differences in changeset 1800 by hand and copy them into the latest version of production to patch it, but I'd like to do this properly if possible.
Aside:
I understand that by applying just a diff, you risk the fact that some of the code involved in the 1799>1800 diff relies on code that was only established between the current production version and changeset 1799, but that can easily be verified by quickly building and testing production after the diff patch is applied. We aren't worried about that.
Ok, I'm not sure I totally understood, but here it is:
Changeset in TFS don't store the absolute content of a file, but the difference (lines added, deleted, changed).
If you want to report your bug fix from the version 6.1 to the 6.0 and this fix is included in the changeset 1800 (and nothing more than this fix), then simply merge the given changeset to the version 6.0. All the changes made before the changeset 1800 won't be merged in the 6.0, only what you did in this changeset will be merged.
When you do a merge you have two options:
Merge all the changes from the source branch to the destination one
Merge a selected changeset from the source to the destination one.
Use the second one and specify the changeset 1800 and you'll be fine.
Some pictures:
ONLY the changeset selected will be merged.
When creating a patch with the "patch" tool or with the built in "patch"-functionality in svn and then applying it to a source tree, is there any way to easily step back from the applied patch to the previous version?
Apply the patch again in reverse (for example patch -R switch).
svn revert? You can revert to the previous revision (before the patch was applied).