Is there a way to do a tkdiff on two Perforce changelist versions of the same file? In my previous job, where svn was used, I could use -r with tkdiff to get revision numbers. For example:
tkdiff -r323262 -r314735 [filename]
That's not working in the Perforce environment. Is there some feature like that with Perforce?
Thanks everyone. What worked best for me was p4v. The Perforce Visual Client let me tkdiff between selectable versions of a file.
Just drop the hash '#n' in the perforce file rev number and pass it to '-r' of tkdiff.
e.g. tkdiff -r4 -r5 filepath will give you the diff between versions filename#4 and filename#5 .
Using p4v is the best way to diff between two files, either by doing 'Diff against Have Revision', or starting 'Revision Graph' on a file, then dragging and dropping between the two revisions you want to diff.
In P4V you can stiff use tkdiff, by going into Edit->Preferences, then changing the Diff program to tkdiff,
tkdiff will then be used for 'Diff against Have Revision' or diffing between revisions in the Revision Graph view.
I used tkdiff in preference to P4Merge for a long time, until I discovered Beyond Compare.
Related
Is there a way to quickly diff a file(edited in my current work area) to same file submitted in an earlier change list in perforce ?
Yes, you can specify any revision of the depot file to diff against. For example, if that 'earlier change list' was change 1742, you can simply do:
p4 diff myFile.txt //depot/path/to/myFile.txt#1742
There are lots of ways to specify the desired revision of the file in the depot. Run
p4 help revisions
for all the details, or see: http://www.perforce.com/perforce/doc.current/manuals/cmdref/filespecs.html
CVS is showing multiple revisions numbers at the end of my file names. Any idea what is going on here and whether I should be worried?
I am not sure how do you sync your files with your CVS. In my case I do sync externally[meaning, not from eclipse] in such case you can select all your projects > Team [on right menu] > Disconnect >do not delete CVS metadata info in next window.
CVS (like RCS, but unlike many other systems like SVN and Git) tracks the revision history of each file independently. In SVN, for example, a given version number applies to the entire repository. In CVS, each file has its own independent history and current version number. Having different version numbers for different files is perfectly normal.
I am new to Mercurial and the Eclipse Mercurial Plugin.
The thing is that I've made a change in a single file, and commit. I have two revisions of this file and I need to make a patch/diff file between the first and the second revision.
Any clues on how I can achieve this with Mercurial/Eclipse Mercurial Plugin?
King Regards,
I don't think you can through the Eclipse GUI. You can certainly export a patch for an uncommitted file or files (Team -> Export Patch).
You will have to use the command line (hg log -p) on the revision you want the patch for.
We use bzr as the version control system at work and we've come to realize that in a certain project, it would be quite handy if each of the revision controlled files had the revision number as a comment on the first line of each file.
In a nutshell I want to add # BZR REV: xxx to each python file during commit.
A quick bash script would achieve this but as I understand this should be standard practice in other version control systems like SVN, so I'm hoping for a builtin way to achieve what I need. Also it would save me the trouble of writing that bash script :)
See the bazaar keywords plugin.
how does version control usually work? does it save diff files as a trail with hashes to validate the trail?
Check out Eric Sinks blog series on version control.
Also, Joel Spolsky wrote Hg Init: a Mercurial tutorial, that finally made me "get" what distributed source control is all about.
There are more than one ways to skin a cat...
Different VCS use different approaches. CVS, for example, will create a file on the server for each file which you commit. This is essentially a file in RCS format; CVS is only a wrapper around RCS which runs the RCS commands over many files in a directory subtree (RCS can only work on single files).
The RCS file contains a list of changes (version number, checkin message and how much was changed). After that comes a copy of the current HEAD version. The rest of the files are the diffs between the versions (long explanation).
This way, CVS can quickly return the HEAD version (which is most often requested) and it can compute the other versions.
CVS doesn't do any validation; if one of your files becomes corrupt, you need a backup. Since CVS is based on RCS, it can't version directories nor can it track renames. CVS and RCS use the standard diff(1) command to create the diffs.
Subversion (SVN) works similarily but adds versioning of directories and renames. Moreover, SVN uses a better diff algorithm (xdelta) which gives a smaller repository.
For an explanation how Git works, see here.
Darcs is very different and IMHO more intuitive than other SCMs even distributed ones.
There's an excellent guide for beginners about how it works: Understanding Darcs.