I've done this several times in git, but not sure how to do it in p4 commandline. Google is not helping me - or maybe I'm not searching correctly.
I have a file that was deleted: /path/to/file/index.html Now, I need to get the contents of that file as it was before being deleted. I do not want to bring it back to life, I just need the contents.
The changelist for the delete is 125325.
What would be the easiest way to do this?
To sync it to your workspace (this is kind of similar to the git checkout method that you're probably familiar with):
p4 sync /path/to/file/index.html#125324
If you just want to see the content (e.g. dump it to stdout), you can use p4 print (if you were to use the depot path of the file rather than a local path, p4 print doesn't require that the file is mapped to your workspace):
p4 print /path/to/file/index.html#125324
Note that the rev specifier I'm using is the changelist before the file was deleted. You can also use the prior revision number, or an earlier rev/changelist, a particular date, etc. See p4 help revisions for all the ways you can reference older versions of files.
Related
I'd like to output ("-o") the content of a file that is version controlled in mercurial. I know this can be done using the cat command.
However, the file I am interested in has been removed, so the cat command fails with a "no such file in rev X" where X was the revision number where the file was removed.
I do not wish to restore the file. How do I output the content of such a file?
One alternative to using cat would be to update to a revision where the file still existed. This would just be:
hg up -r$REV
as long as you're sure it still existed in $REV. Then you can just navigate to the file normally & view it, copy it somewhere, etc.
The usual considerations apply when doing any update - i.e., you generally need a clean working directory.
If you are using TortoiseHG, you could also use the "browse" feature to do something similar.
In THG Workbench, scroll down to the revision that still has the file. Then right click "Browse at Revision". This will show a treeview of the entire repository at that revision. You can just pick the file out of the tree and save it, etc.
hg cat -r$REV $FILE
where $REV is the revision of the file you wish to view and $FILE is the filename.
If you are unsure of the revisions you can use hg log $FILE to show you the history, so you can choose a revision before it was deleted.
I want to test a fix and to compare the behavior before the fix vs. now; I need to sync to a the earlier version. So, if the fix was committed in revision x; how can I sync to one revision before, say x0?
Say that you want to go back to revision 'n' from revison 'n+1' (rollback). You can take the following steps:
p4 sync ...#n
This will sync your files to the older version that you want
p4 edit ...
Open all the files for edit or do "p4 edit filename" to open only a particular file for editing.
p4 sync ...#n+1
Before submiting you need to sync files to the latest revision on the repository.
p4 resolve -ay
This will accept the changes that you have made, ie, revert all the changes done when you moved from revision 'n' to 'n-1'. So effectively, all your files have been rolled back to revision 'n' in your local repository.
p4 submit ...
Go ahead and submit the changes. This will roll back all main repository to revision 'n'. Effectively the revisions 'n' and 'n+2'(current) will be identical.
p4 diff2 -q repository#n repository#n+2
This is just to verify if have rolled back the files. This should show that you have no differing files in the two revisions.
I found the answer while writing my question. I have been trying:
p4 sync ...#x0
where x0 is the changelist before the change containing the fix. But only a fraction of files was getting reverted. I found the issue that when we specify ... only the files in that folder and subfolder(s) get synced. So above command should be executed from the root of the workspace.
If you want to sync a specific version number (not changelist number) for a specific file. This worked for me:
p4 sync //your/depot/path/and/file.name#1
to verify you have the version you want, you can use the have cmd
p4 have //your/depot/path/and/file.name
I am looking for a perforce command to get the list of the files that have been modified locally and "not" checked-in to the repository.
I understand that I "should" get the list of modified files in Pending changelist, but there are scenarios when I don't get to see a modified file in that list. And then on "manually" checking out a file and doing a diff i realize the difference.
Is there any command that could check all the files in a given folder and provide me a list of files that are not same as there state in the repository?
I tried "p4 sync", but that did not work.
Thanks for your interest.
Try
p4 diff -f -sa
(see manual for further details)
I use "p4 revert -n ./..."
where
-n
List the files that would be reverted without actually performing the revert.
This lets you make sure the revert does what you think it does before actually reverting the files.
In the recent versions of Perforce, try "p4 reconcile -e"
see: http://www.perforce.com/perforce/r12.1/manuals/cmdref/reconcile.html
It certainly takes its time though (not very fast).
I think, the modified files are submitted locallay (Otherwise, p4 opened ./... will help to find)
If files are already submitted to local perforce and still want to know which all are modified..
p4 changes -m 5 ./... (Should give changes lists)
p4 integrate -n ./... //server/code/base/... (This should list the files to be integrated to mainline.
I have a directory outside the repository. I put generated sources in there. These generated sources take FOREVER to create. Rather than have everyone on the team generate these sources, I would like to use our build machine to generate the sources, and check them in to perforce. How do I do this and ensure that the source controlled directory only has only the most recent files and not any that were generated previously but not in the most recent build?
I was thinking of doing a p4 edit on all the files in the generated directory (for existing files), then doing a p4 add using wildcards to get any files that are new, but I do not know how to handle files that were previously generated, but not generated in the most recent build (should be deleted).
Start as you suggested - p4 edit and p4 add to capture all changes, then call
p4 revert -a
Which will revert any file in the depot that is open for edit but is actually unchanged or missing.
I found this on the perforce blog and it is exactly what I was looking for. Automating folder replacement using P4Java and Apache Ant
One idea is to, before the build, removing everything in this area manually (not through Perforce, but through the OS). After doing the build, do a "Reconcile Offline Work". This will reconcile in Perforce what you have in this area by adding new files, deleting ones that are not there anymore, and editing those that have changed.
You can reconcile offline work through P4V, as seen here. In your workspace browser, right-click the folder and choose "Reconcile Offline Work".
Or, you can do it through the command line if you prefer a more automated solution, as seen here. (Note: this link also talks about reconciling through p4v, but this is superseded by the previous link)
p4 diff -se //myclient/... | p4 -x - edit
to checkout changed files.
p4 diff -sd //myclient/... | p4 -x - delete
to delete files.
find . -type f -print | p4 -x - add
find . -type l -print | p4 -x - add
to add files and symlinks in Unix, or
dir /s /b /a-d | p4 -x - add
to add files in Windows.
For Binary files in Perforce you can set a FileType flag that only stores 1 (or a set number ) of revisions for the file in the repository. This way you will have history of the file but your other users will only have access to the binary for the latest version of the file and also your server will only store one copy which is much more storage efficient if you dont need to store multiple copies.
To make the change.
Add the files you are interested in to the repository.
Check out the file.
Right click in P4V and select Change Filetype
On the dialog pops up select +S "Server limits the number of revisions stored" at the bottom of the screen, which will restrict the number of files stored.
Hope this helps.
I have a file with database settings in my project which I have set to some defaults. The file is tracked by Mercurial and checked in. Since this file will be edited with different values various developer machines, is there a way I can tell Mercurial to ignore new changes to this file?
I tried adding the file to the .hgignore file, but since the file is tracked it isn't ignored. This is alright and good in other situations, but I am wondering if there is something I can do here?
Using a file template is definitely the best solution.
For example, if you have a database.ini file, commit a database.ini.template file and ignore database.ini in .hgignore
If you always want to ignore the file, you can add the -X option as a default for commit to your .hg/hgrc configuration file:
[defaults]
commit = -X program.conf
We wrote an extension for this called exclude. It will automatically add the -X options on the commands that support them -- so hg status and hg commit wont see the modified file. It works by reading a .hgexclude file from the root of your repository, just like the .hgignore file. You add the files that you want to exclude there:
syntax: glob
db.conf
The extension works quite well, but there is a known situation where it fails: merges and the commit that follows a merge (this is documented on the wiki). It would need to be improved so that it would save the modifications away to a temporary file and then restore them afterwards. Please get in contact if you need this feature.
There is no truly automated process, but you can try (as in this SO question) the -X option on hg commit:
% hg stat
M myfile
% hg commit -X 'myfile'
(other solutions might involve shelve or hq)
However, this is not the "right" solution. I would rather recommend versioning:
a file template
a script able to generate the final file (that you modify but can ignore altogether)
If you are using TortoiseHG, open the Settings for the repo, go to the Commit section (2nd icon down on the left) & add the file name(s) to the Auto Exclude list on the right (~ 3rd from the bottom in the list).
From https://tortoisehg.readthedocs.io/en/latest/settings.html#commit
Typically you would check in a reference copy of the file and track it then have the developers make a copy of that for local development, you wouldn't really want developers editing the source controlled file for their own environments.
If your configuration system supports it, it's even easier if you can use an override file that simply override values in the reference copy (e.g. the database connection string). That way devs only have to keep a very minimal local set of override values.
If the file is already being tracked, you can issue the Forget command to the file. If you're using TortoiseHg just right click the file during commit and select Forget. The file must also be already in the ignore list.
I had the same problem as yours, I file keeps on appearing on every commit even-though its already in the ignore list. I tried the Forget command and it did the trick.
You can try hg forget.
For more details, see the official manual about the same command.
It worked for me.
I think, something like this is closer to a correct answer to the original question Mercurial: How to ignore changes to a tracked file, rather than the others suggesting a template, etc.