How do you quickly find/delete all empty changelists in Perforce? - perforce

I was wondering what could be the point in trying to delete committed changelists, because a committed changelist is not supposed to be empty.
But then I am playing with the tutorial depot, and using the obliterate command on a whole branch, I can see there are situation where you can end up with empty committed changelists (that need deletion with the -f flag).
However, I don't know how to find them with the command line, as I don't know how to look for changelists with no files associated with.
Is there an easy way to do that ?
Thanks,
Thomas

Ah !
I should have browse more documentation before asking this...
http://public.perforce.com/wiki/Perforce_Command_Line_Recipes
Description: Delete all empty submitted changelists.
Shell command: p4 changes -s submitted | cut -d " " -f 2 | xargs -n1 p4 change -d -f
Powershell: p4 changes -s submitted | %{p4 change -d -f $_.split()[1]}
px: px -F %change% changes -s submitted | px -X- change -d -f
Contributors: Sam Stafford, Philip Kania, Shawn Hladky
Duh.
Thomas

To simply find all empty submitted changelists without deleting them, you can compare the output of these two commands:
p4 changes -s submitted - all changelists
p4 changes -s submitted //... - all changelists with associated files
In Windows PowerShell, for example, run
diff -ReferenceObject (p4 changes -s submitted) -DifferenceObject (p4 changes -s submitted //...)

As I am on Windows, I have created a little script doing the exact same thing in PERL, rather than Shell, powershell or px :) :
#*******************************************************************************
# Module: delete_empty_changelist.pl
# Purpose: A script to delete empty changelist
#
#list = `p4 changes -s submitted`;
foreach $chg (#list)
{
$chgnbr = (split /\s+/, $chg)[1];
print `p4 change -d -f $chgnbr`;
}
exit 0;
Note that in fact, in all cases, it's not a very clever script: It tries to delete absolutely every submitted changelist, and is prevented by perforce to do so, because if files are associated with it, you will get an error.
I suppose the result of the script should be sent to a log, and parse, so that only the relevant lines are highlighted.
Running the script will produce an output similar to:
Change 857 has 1 files associated with it and can't be deleted.
Change 856 has 1 fixes associated with it and can't be deleted.
Change 855 has 1 fixes associated with it and can't be deleted.
Change 854 deleted.
Change 853 has 1 fixes associated with it and can't be deleted.
Change 852 has 8 files associated with it and can't be deleted.
Change 851 has 1 files associated with it and can't be deleted.
Change 850 has 2 files associated with it and can't be deleted.
Change 849 has 2 files associated with it and can't be deleted.
Change 846 deleted.
Change 845 has 2 files associated with it and can't be deleted.
Cheers,
Thomas

Here is a DOS CMD only version. Just replace %p4streamsUser%.
for /f "tokens=* delims=" %%i in ('p4 changes -u %p4streamsUser% -s pending') do (
for /f "tokens=1-7*" %%a in ("%%i") do (
echo Deleting CL %%b %%h %%f
p4 change -d -f %%b
)
)
I'm on a Windows 7 machine. This will work on several other versions of windows/DOS.

Related

how to handle files/directories with '#' in perforce

I have some folders with '#' in it.
I can't seem to make it work
>cd fmsn_adc_vs_cdc_clock_reset_integrity#fmsn_adc_vs
>p4 rec -n ...
//depot/icm/proj/i10soc2/fmsn_lib/cdc/dev/fmsn_adc_vs/results/fmsn_adc_vs_cdc/consolidated_reports/fmsn_adc_vs_cdc_clock_reset_integrity%40fmsn_adc_vs/spyglass.log - can't reconcile filename with wildcards [##%*]. Use -f to force reconcile.
... - no file(s) to reconcile.
>cd .. >p4 rec -n 'fmsn_adc_vs_cdc_clock_reset_integrity#fmsn_adc_vs/...'
Invalid changelist/client/label/date '#fmsn_adc_vs/...'.
No file(s) to reconcile.
How can we handle files/directories with '#' ?
Is there any documentation I can refer to?
Thanks in advance.
The first error message gives you the exact answer:
Use -f to force reconcile.
Just add -f to the command you tried the first time:
p4 rec -n -f ...
This will automatically translate the # to %40 in the depot path when it opens the file for add. From that point on, if you need to refer to that file by name, use %40 in place of #. It will still have the # in its local path.

Execute p4 aliased command result in messed wrong order of lines in output

I have the following content inside my p4aliases.txt.
diff-cl $(target-cl) = diff -dl //...#$(EQ)$(target-cl)
Basically it diffs against your files in current workspace toward the target shelved files of changelist.
It is fine. I can execute it. But when I compare the result coming from above aliased command against the direct raw (non-aliased) command as follows
p4 diff -dl //...#=<target-cl>
the output lines of text from aliased command is in wrong order e.g. changes according to a certain file shows up first before a line of file shown, line orders are messed up. This is not the case if you execute with a non-aliased command.
Example
Expected result
==== //depot/common.h#none - x:\mydir\project\src\common.h ====
==== //depot/file.cpp#none - x:\mydir\project\src\file.cpp ====
3a4
> added line 1
==== //depot/file.h#none - x:\mydir\project\src\file.h ====
Actual result
3a4
> added line 1
==== //depot/common.h#none - x:\mydir\project\src\common.h ====
==== //depot/file.cpp#none - x:\mydir\project\src\file.cpp ====
==== //depot/file.h#none - x:\mydir\project\src\file.h ====
I have p4 version as of Rev. P4/NTX64/2021.1/2126753 (2021/05/12).
Perforce server version (got from p4 info) is Server version: P4D/LINUX26X86_64/2017.1/1574018 (2017/10/02).
How can I solve this issue?
Could this be a version too far away between client and server
Update
I have tested p4 client all the way down from 2016-2020 version by downloading old binaries from ftp.perforce.com (in directory perforce). No luck. Output still messed the same. So it's not the problem about version mismatch.
This looks like a bug in the p4 client. When the client does a diff, it's written by the ClientUser::Diff() method, which defaults to writing to stdout (i.e. it does not route the output through ClientUser::OutputText()):
https://workshop.perforce.com/projects/perforce_software-p4/files/2018-2/client/clientuser.cc#436
https://workshop.perforce.com/projects/perforce_software-p4/files/2018-2/client/clientuser.cc#573
Output from commands run as part of an alias go through the ClientUserStrBuf subclass, which buffers all of its output. The file headers, for example, are buffered by ClientUserStrBuf::OutputInfo():
https://workshop.perforce.com/projects/perforce_software-p4/files/2018-2/client/clientaliases.cc#1647
There isn't a ClientUserStrBuf::Diff() implementation, though, so that diff output goes straight to stdout while the headers are buffered and printed at the end (presumably after some post-processing) -- hence the diff output showing up first in the console.
The fix I'd make would be to have the base ClientUser::Diff() implementation route the output through OutputText() when no output file is provided, which seems like the least-surprise behavior; that'd fix the aliases behavior and might even make life a little easier for other client developers who would otherwise hit the same issue. If you have a support contract with Perforce you can file this as a bug report, or since the client is open source you can take a crack at fixing and building it yourself. I don't think there's a workaround that doesn't involve modifying the client source code.
Samwise has the correct approach to truly fix the problem at hands although it might take some effort to understand the code, and conduct the fix itself.
At any rate, if we took such approach we won't be able to take benefits of bug fixes and future updates as we will be stuck with 2018-2 version of p4 as it's the latest as it can be in which we can grab the source.
I would recommend to use WSL then interact with p4.exe (yes, a Windows-based binary) for Windows-based project, and p4 for Linux-based binary. If you didn't use WSL, please find the .bash_aliases-like solution as I have below to seamlessly solve aliases diff operation.
Put the following code into your ~/.bash_aliases
# p4 - fix of aliases diff operation
# platform independent, it will choose a correct binary path to execute properly
p4() { cmd="p4.exe" # default is Windows-based
# get the last argument value, if "-lx" passed in then we know it's linux
if [[ "${#: -1}" == "-lx" ]]; then
cmd="/usr/local/bin/p4"
fi
if [[ $1 == "diff-cl" ]]; then
if [ -z "$2" ]; then
echo "usage: p4 diff-cl <CL>"
return 1
fi
$cmd diff -dl //...#=$2 | diffp4 | less -r
elif [[ $1 == "diff-cl-fonly" ]]; then
if [ -z "$2" ]; then
echo "usage: p4 diff-cl-fonly <CL>"
return 1
fi
$cmd diff -Od -dl -ds //...#=$2 | diffp4 | grep ==== | less -r
else
$cmd "$#"
fi
}
then source ~/.bash_aliases.
What it does is to allow you to still use p4 with all of its original commands & arguments normally with exceptions of diff-cl (which is the same name of alias I've put into p4aliases.txt for Windows or ~/.p4aliases for Linux). You can safely remove diff-cl entry from p4's alias file, or just leave it there. What we have in ~/.bash_aliases file will intercept whenever such argument matches then execute the raw command, just that we don't have to type long command ourselves.
We can later remove such section in our ~/.bash_aliases file when upstream p4 has been fixed.
In else section, we just relay the the whole arguments, and it will be performed just as normally done.
Extra: diff-cl-fonly to list out only files (its depot path, and local workspace path) which have changes.

Git is not working with vimdiff

I am using meld with git for merging and I want to try vimdiff. Configured three way merge with git and then my own diff command:
[merge]
tool = vimdiff3
conflictstyle = diff3
[mergetool "vimdiff3"]
cmd = gvim -f -d \"$LOCAL\" \"$BASE\" \"$REMOTE\" \"$MERGED\"
But everytime I try to run mergetool, git just quickly respond "[file] seems unchanged" and skips the merge.
On top of that, I'd like to get real three-way merge (four files) with merged window in the bottom, this shold work but I saw many reports it is not working on the internet:
cmd = gvim -f -d -c \"wincmd J\" \"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"
You could check if the upcomming mergetools/vimdiff3 setting (for git 2.0.x Q3 2014) would work for you.
See commit 7c147b7 by Felipe Contreras (felipec), merged only recently in commit 3a9dae7 (June 2014):
mergetools: add vimdiff3 mode
It's similar to the default, except that the other windows are hidden.
This ensures that removed/added colors are still visible on the main merge window, but the other windows not visible.
Specially useful with merge.conflictstyle=diff3.
gvimdiff3|vimdiff3)
if $base_present
then
"$merge_tool_path" -f -d -c 'hid | hid | hid' \
"$LOCAL" "$REMOTE" "$BASE" "$MERGED"
else
"$merge_tool_path" -f -d -c 'hid | hid' \
"$LOCAL" "$REMOTE" "$MERGED"
fi
;;
The new file mergetools/vimdiff3 has been added, which means that all you would need to do is:
git mergetool --tool=vimdiff3
(without having to configure mergetool.vimdiff3.cmd)

Perforce: How to find the original number of a change list

In perforce changelists get renumbered on submission. So for e.g. when the changelist was created it would be numbered 777 , but on submission of changelist it would get renumbered to say 790.
My question is how do I get the new CL number (790) , if I know the old CL number 777 , or vice versa ?
If you really want the original changelist number, that can be retrieved from Perforce without having to embed the original changelist number in the description. You can use the -ztag command line option to get at it. And you can only get at it through the 'changes' command (as far as I know):
d:\sandbox>p4 submit -c 24510
Submitting change 24510.
Locking 1 files ...
edit //depot/testfile.txt#2
Change 24510 renamed change 24512 and submitted.
d:\sandbox>p4 -ztag changes -m1 //depot/testfile.txt
... change 24512
... time 1294249178
... user test.user
... client client-test.user
... status submitted
... oldChange 24510
... desc <enter description here>
<saved
As pointed out, it's probably not that useful. However, I did want to note that it's possible to get at it.
The only way I can think of is adding the original changelist number as part of the changelist description field. First, you'll need a script to store the original changelist number:
#!/bin/env perl
$id = $ARGV[0];
open (CHANGE_IN, "p4 change -o $id|");
open (CHANGE_OUT, "|p4 change -i $id");
while (<CHANGE_IN>)
{
if (/^Description:/ and not /ORIGID/)
{
s/(^Description:)(.*)$/$1 ORIGID $id. $2/;
}
print CHANGE_OUT $_;
}
close (CHANGE_IN);
close (CHANGE_OUT);
Save this as origid.pl on the Perforce server with the executable bit set. Then setup a trigger with p4 triggers.
Triggers:
add_origid change-submit //depot/... /usr/bin/origid.pl %change%
Version 2012.1 of Perforce introduced the -O (capital oh) argument to p4 describe, which allows you to query a changelist by its original number (before being renumbered by p4 submit).
I find this very helpful, since I often find myself keeping notes about a changeset before it is submitted, then forgetting to note what it was renumbered to on submission.
So if I have a note talking about change 12300, I can now see what it refers to by typing:
p4 describe -s -O 12300
and having Perforce tell me:
Change 12345 by me#myhost on 2013/10/31 00:00:00
Fix that thing I wrote that note about
Affected files ...
... //Proj/MAIN/foo.c
The ztag method mentioned earlier can be used to find the old changelist number of a submitted change:
> p4 -ztag describe -s 12345 | grep oldChange
... oldChange 12300
Adding to Eric Miller's reply, because I can't comment (not enough points):
to just emit the 1 number
p4 -ztag describe $ORIG | sed -e 's/^\.\.\. oldChange //;t-ok;d;:-ok'
e.g.
OLD=$(p4 -ztag describe $ORIG | sed -e 's/^\.\.\. oldChange //;t-ok;d;:-ok')
or if you want to look up many numbers, this will output a map of new old on each line (may be useful with the "join" command). If there is no old commit, then it re-emits the new commit.
p4 -ztag describe 782546 782547 ... | sed -e '${x;p};s/^\.\.\. change //;t-keep;b-next;:-keep;x;/./p;g;G;s/\n/ /;x;d;:-next;s/^\.\.\. oldChange //;t-ok;d;:-ok;H;x;s/ .*\n/ /;x;d;'
I tried to avoid using GNU extensions to sed.
Unless you do something like Tim suggests the old change list number will be lost on submission.
Change list numbers are only temporary until you actually submit. So if you create a new change list (777 say) and then decide to delete it, the next change list you create will be 778.
It can be a bit more elegant if you use the P4 Python module.
i.e.
import P4
p4 = P4.P4()
p4.connect() # having a valid p4 workspace/connection is on you :)
c = p4.run_describe('969696') # describe a Submitted, renumbered changelist, i.e. 969696
old_pending_cl_number = c['oldChange'] # print out prior/pending CL# if this exists.
Cheers

Is there a script that would allow me to edit multiple files as if they are one file in VIM?

I prefer to edit in one large file rather than many independent files, but due to limitations in languages, source control, and the preference of team mates I need to output to many files.
What I'm looking for would recurse through all the files in a source directory and generate a single file to edit in VIM, with special file seperator markers. On save it would save the the changes to the correct file(s) ideally in a smart manner, based only on changes made.
Does something like this exist?
shar
Well, you could use shar(1), but it puts an X in front of each line that you will probably find annoying. (Shar came with my Mac but on my Linux systems you need to add a package.)
Shar is just, itself, a short shell script, so you could modify it easily enough to work without the X.
You might try copying /usr/bin/shar to /tmp and applying this diff with patch(1).
--- /usr/bin/shar 2009-07-13 22:26:18.000000000 -0700
+++ /tmp/shar2 2010-12-24 19:05:34.000000000 -0800
## -65,8 +65,8 ##
echo "mkdir -p $i > /dev/null 2>&1"
else
echo "echo x - $i"
- echo "sed 's/^X//' >$i << 'END-of-$i'"
- sed 's/^/X/' $i
+ echo "cat >$i << 'END-of-$i'"
+ cat $i
echo "END-of-$i"
fi
done
It reminds me of vimballs format. However, it's meant to expand files into the user runtimepath directory.
In other words, you can list all the files you want join and apply :MkVimBall (here is an example).
Then, for the extraction, you will have to momentarily (i.e. save and restore its value after the extraction) set &runtimepath to the root directory of your project before extracting with :so %.
You'll also have to play with various options like the &filetype, etc.
It's a dirty hack, but well ... it shall do the job.
Instead of dumping several files into one, processing this one and then separating stuff apart again, you could use bufdo or windo to repeat a command on all opened buffers: open the buffers to be processed, then cast the bufdo command and it will work on every opened file: http://vimdoc.sourceforge.net/htmldoc/windows.html#list-repeat

Resources