I'm extremely new to perforce and wasn't having very much luck searching online... but...
Is there an way to get a list of all the files that have changed since a specific revision number? I'm going to have to push something to our production server and instead of going through all of the files and checking, I'd like to tell Perforce to give me any files that have change since revision X.
Personaly I think it makes a lot more sense (and I believe it is much faster) too work with changeslists instead. Something like:
p4 changes /myrepository...#changelist
Please note that revisions and changelists are not the same thing in perforce.
In perforce you have revisions of a file for example revision 3 means the 3'rd change to THAT file. You also have changelists which map of the whole perforce depot. They represent a bunch of changed revisions mapped together when you commit. So for example you commit 3 files (file1: rev 3 file2: rev 5, and file3 also at rev3) and the changeset could be something like 5200 since you have committed 5199 times before this new commit.
Hope that helps.
While the p4 changes command is good, it shows all the changelists, not all the individual files that have changed. Google leads folks to this question when they are searching for how to list all files with Perforce, as that's what the question asked.
To list the files that have changed between your #start,#stop times,
p4 -c WORKSPACENAME files //Path/You/Care/About/...#2013/03/20:13:40,#2014/06/016:17:00
You can start with p4 changes:
Use p4 changes to view a list of submitted and pending changelist
# Display all changelists submitted from April 1, 2001 to the present.
p4 changes #2001/04/01,#now
From there, to display the files in each changelist, see p4 describe as detailed in "Is there a single Perforce command to display a list of all the check-ins to a file/dir along with the list of files that changed and the description?".
If you want all the files up to a particular change, then use the 'p4 files' command.
For example:
$ p4 files //...#7
//depot/dev/fileA#2 - edit change 7 (text)
//depot/dev/fileB#2 - edit change 7 (text)
//depot/dev/fileC#2 - edit change 7 (text)
//depot/main/fileA#1 - add change 1 (text)
//depot/main/fileB#1 - add change 1 (text)
//depot/main/fileC#1 - add change 1 (text)
//depot/r1.0/fileA#1 - branch change 2 (text)
//depot/r1.0/fileB#1 - branch change 2 (text)
//depot/r1.0/fileC#1 - branch change 2 (text)
If you want files for only one particular changelist then use the #n,#n notation such as:
$ p4 files //...#7,#7
//depot/dev/fileA#2 - edit change 7 (text)
//depot/dev/fileB#2 - edit change 7 (text)
//depot/dev/fileC#2 - edit change 7 (text)
More details on 'p4 files' is found in the command reference:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_files.html
More details on file specifications here:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/filespecs.html
Related
I'm in the process of doing a merge, and I'm ready to commit at this point but my commit dialog in TortoiseHg is showing many files as modified but when I diff to parents it says all files are binary equal.
I do not have and have never had the eol extension enabled.
Revert changes nothing, the file is still registering as modified.
hg parents shows two parents for the file.
hg stat shows the file as modified, e.g.
c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs
M Authorization\AuthorityGroups.cs
hg diff --git shows nothing, e.g.
c:\Projects\MyProject>hg diff --git Authorization\AuthorityGroups.cs
c:\Projects\MyProject>
I've tried this on two different machines on two separate clones and I'm seeing the same thing.
Any other thoughts for how I could diagnose or fix this?
Clearly something has changed but if it's not showing in hg diff --git how can I establish what that might be?
Update 2014/12/10:
I've done a bit more checking on the history of the two parent revisions and I think I see why it's getting confused.
We've got the original parent file added in revision 1 on default.
On the Apple branch the file has been renamed to move it to a new location.
On the Orange branch the file has been added to move it to the same new location.
So the file on both branches is binary identical and at the same location, but presumably Mercurial is flagging it as a difference to be merged because they arrived there by apparently different means.
So the question then becomes:
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history) , or do I just need to let it go through in the merge?
Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history)
Well... sort of. Update to the most recent Orange commit in which the files had their old names (you can use hg bisect to find it if you're not sure exactly when it happened), do hg rename to the new names, commit, and then merge this into the current Orange head. Mercurial should be smart enough to register the files as properly renamed, and it won't cause conflicts (we know this because the more complex Apple/Orange merge didn't).
or do I just need to let it go through in the merge?
This is easier. Mercurial's merging algorithm is quite smart. It can deal with situations like this just fine.
Unless you have a third branch in which the files were never moved, the second option is unlikely to cause a problem. If you do have such a branch, you should be fine as long as you merge it into a descendant of the Apple rename (or merge from such a descendant). The major difficulty would be with merges to or from the Orange branch.
I have a source file //code/main/Foo.cpp whose line N was changed. After a combination of p4 annotate and p4 filelog, I found the change came in from a branch. (This is my understanding of e.g., git blame.)
Drilling into that branch I again used a combination of p4 annotate and p4 filelog to find the line change came from an integration from yet another branch.
Drilling into that branch I again used a combination of p4 annotate and p4 filelog to find the actual changelist that contained the original submission that eventually led to changing line N in //code/main/Foo.cpp.
Is there no easier way to do this? I would like to point to a line in a file and say, "Where and when did that line first appear as currently written in the depot?"
What I want, then, is a deep git blame that traces a change all the way back to its origination.
You can use p4 annotate -i to follow history if the file was branched and p4 annotate -I to follow history from integrations to the file.
How do I get perforce diff's sorted by order in which changes were made .
can we have output of diff only after certain date .
Solutions to above output only for certain user, files..
You would definitely have to write a tool to do this efficiently, but here's some pointers
p4 changes Documentation
This command allows you to list every changelists that fit with certain criteria such as -u user for a specific user, #date for everything before date, #date1,#date2 for anything submitted between date1 and date2, /depot/location' to retrieve only changelists affecting files in/depot/location`, etc... check documentation for more.
It will output a list items formatted like this:
Change ChangeNumber on Year/Month/Day by User#WorkspaceName 'Shortened Description'
Now that you have the changelists, you need to see the details of them, so parse your output from p4 changes and then call p4 describe.
p4 describe Documentation
This command allows you to get the description of a changelist by providing its ChangeNumber (from our change output).
The output of this command will look something like:
Change ChangeNumber by User#WorkspaceName on Year/Month/Day Time
*new line*
*tab*Full Description
*new line*
Affected files ...
*new line*
... //depot/path/file#RevisionNumber operation(add/change/delete...) // repeated for as many files that were in the changelist
p4 diff2 Documentation
This command will now allow you to diff two revisions on the depot. You can use flags sur as -ds to only have a summary. Not providing a revision number will use the HEAD revision.
As an example, I added // test and a new line to a document, testing it against its previous revision gives this kind of output
==== //depot/path/file#RevisionNumber (text) - //depot/path/file#2ndRevisionNumber (text) ==== content
2a3,4
> // test
>
p4 diff Documentation
diff will be very similar to diff2 but it diffs with the file on the machine, useful if you have pending changes.
This should help you get started!
I have a file that was deleted a few changesets ago. As you can imagine, the other files in my project have changed since then. How can I get back that file (it's actually 2 files) without reverting all the other source files?
Use hg revert for just that file:
hg revert -r REV path/to/deleted/file
From the help for hg revert
If a file has been deleted, it is restored. If the executable mode of a file was changed, it is reset.
If names are given, all files matching the names are reverted. If no arguments are given, no files are reverted.
Another approach to this is to use the Kiln website. You can search for a changeset by changeset id, or just use a date search, .e.g. date:2011-10-01..2011-10-31
That will then give you a list of changesets, click the one that will show the version of the code you want to recover, and then if you click the Browse files at [changeset id] link on the right hand side you will then get a list of the folders and files at that point in time.
You can then just add new files to your project and cut and paste the code back into those new files.
Admittedly this isn't as nice an approach for recovering a whole file, but it's handy if you only want to recover part of the code, or if someone has subsequently added a new file with the name of the old file.
vimdiff helps in showing the diff of two files graphically and allows us to pick the changes from left to right/right to left.
The files I am dealing with are huge files and most of the differences vimdiff reports can be auto-merged except a few.As it takes lot of time to go diff by diff in vimdiff and take the action.
I would like to know if there is an option available in vimdiff that automerges the differences in left and right files as long as there is no ambiguity and leaving the conflicted resolutions similar to the tools svn merge and cvs merge tools does?
Its not possible to auto-merge the changes in two files unless we have a base copy where these two files branched and changes done separately. If an item is on one side and not on the other,it can't judge whether this item was newly added or an existing item was deleted. As there is a base copy exists while merging files in a repository, cvs merge,svn merge can auto-merge the changes.
If you use no version control, you can try diff and patch this way:
Before changing your file (say, file.txt), make a backup of the original version (file.orig).
When changed are made, make a patch-file: diff file.orig file.txt >patch.txt
Get a file which you want to merge changes to (say, file2.txt).
Use patch: patch file2.txt patch.txt
Changes will be merged, conflicted rows will be placed in a separate file.
Looks like vimdiff does not allow that. Man page says
"vimdiff - edit two or three versions of a file with Vim and show differences"
But you can have a look at Kdiff3 which lets you compare and merge.