Im trying to automate deployment of perforce (p4 & p4v) using puppet. For this I have created a perforce resource
perforce { 'p4' :
version => '>= 15.1',
ensure => 'present',
}
The problem I have is how to determine installed version. Perforce sort all tar balls in release order .../R15.1/... but running p4 -V yields a version number that looks more like date and build no , e.g. 2016.2.345671
Is there a way that I can get the release installed?
I'm not really sure what you're asking since it sounds like you already know about p4 -V, but will try to answer the implied question of "what do all the pieces of the version string mean"...
"2016.2" is the same as "r16.2" -- releases are named according to the year of release, and there have historically been two major releases most years so the version numbers tend to be of the form YEAR.1 and YEAR.2.
The number at the end of the version string in the binary is basically the patch level (it correlates with changes in the release notes).
Here's an example of using a regex to deconstruct a Perforce version string:
https://swarm.workshop.perforce.com/files/guest/sam_stafford/scripts/itest.pl#401
Related
Is There any Options to Clone a Word / Excel / Presentation Based on document version number
for Ex:
version - 4
version - 3
version - 2
version - 1
Here I need to clone Version 4 In Onlyoffice Document Integration Server
and without any mismatch of editor contents
here I uploaded the image in that 7 version are there, I need to clone a 4'th version (which means version 4,3,2,1 and I don't want 5,6,7) it's not like rollback, original document should not get change while cloning.
Please describe the case more detailed, we need more information about the whole process, i.e. are you going to just copy the file or start a new conversion process?
Could you please specify if the versioning already works in your environment.
If yes, how is it organized.
I am using GitVersion (version 3.5.3 if it matters), and getting some unexpected results; specifically the produced version has an unexpected commit count portion. Looking at the log I can see the commit count is calculated correctly, but the base version used by GitVersion is wrong (or at least not what I thought it would be).
However the log file for GitVersion is less than helpful, it just lists a series of tags, then a long list of merge bases, and at the end it just says which base version it decided to use.
Can GitVersion let me know somehow why it chose that specific base version?
I am not sure, you already checked or not; but it is explained how they calculate base version and also new versions in their documentation
UPDATE: Added main information from documentation.
Architecture
GitVersion has three distict steps for calculating versions in v3.0.
If the current commit is tagged, the tag is used and build metadata (Excluding commit count) is added. The other two steps will not execute
A set of strategies are evaluated to decide on the base version and
some metadata about that version. These strategies include
HighestReachableTag, NextVersionInConfig, MergedBranchWithVersion,
VersionInBranchName etc
The highest base version is selected, using that base version the new
version is calculated.
Visually it looks something like this:
Base Version Strategies
HighestTagBaseVersionStrategy - Finds the highest reachable tag from
the current branch
VersionInBranchBaseVersionStrategy - Extracts version information
from the branch name. eg release/3.0.0 will find 3.0.0
ConfigNextVersionBaseVersionStrategy - Returns the version from the
GitVersion.yaml file
MergeMessageBaseVersionStrategy - Finds version numbers from merge
messages. eg.
Merge 'release/3.0.0' into 'master' will return 3.0.0
FallbackBaseVersionStrategy - Always returns 0.1.0 for new
repositories
Each strategy needs to return an instance of BaseVersion which has the following properties
Source - Description of the source. eg `Merge message 'Merge
'release/3.0.0' into 'master''
ShouldIncrement - Some strategies should have the version
incremented, others do not. eg ConfigNextVersionBaseVersionStrategy
returns false, HighestTagBaseVersionStrategy returns true
SemanticVersion - SemVer of the base version strategy
BaseVersionSource - Sha of the source. Commits will be counted from
this Sha. Can be null (eg ConfigNextVersionBaseVersionStrategy
returns null)
BranchNameOverride - When useBranchName or {BranchName} is used in
the tag configuration, this allows the branch name to be changed by a
base version. VersionInBranchBaseVersionStrategy uses this to strip
out anything before the first - or /. So foo ends up being evaluated
as foo. If in doubt, just use null
I am trying to figure out a rather stable way to programmatically determine the latest release version number of the chrome browser.
It doesn't have to be failproof as it's only a nice-to-have-feature I can blend out whenever the result looks "suspicious".
There seems to be no API (is there?).
I dont want to rely on third parties handling that stuff manually.
I dont want to parse any website output.
So I ended up fetching git files.
My first approach was to fetch this file:
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/VERSION?format=TEXT
Which gives the latest version number.
From there on the solution is just a preg_match_all away ...
Unfortunately its not the latest release version but the latest dev version.
There seems to be no "release" branch nor a "release" tag or something else I can think of neither.
You might answer "why?"... I know about feature detection, I know browser sniffing can be fooled and I am aware of the fact that (every) browser will notify their users when it's time to update. Still makes sense in my case. On the other hand its solely for display purposes. Nothing is going to depend on it later on – promise :-)
Any – even the faintest – ideas are highly appreciated!
The Chrome team uses the OmahaProxy dashboard to keep track of current versions in stable/beta/dev/canary. If you can scrape that you can get whatever version number you're looking for.
I've found the following endpoints from OmahaProxy that give the latest stable versions of the respective OS.
Windows: https://omahaproxy.appspot.com/win
Linux: https://omahaproxy.appspot.com/linux
Mac: https://omahaproxy.appspot.com/mac
Feel free to use my online service vergrabber to get latest versions of different kind of software in json format.
It's available at http://vergrabber.kingu.pl/vergrabber.json
If you're on debian based linux, you could install and update your chrome once a day, and somehow parse the version number, but this is not realtime.
For example:
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
dpkg -i google-chrome-stable_current_amd64.deb
Which will give a log like this:
(Reading database ... 113338 files and directories currently installed.)
Preparing to unpack google-chrome-stable_current_amd64.deb ...
Unpacking google-chrome-stable (48.0.2564.97-1) over (47.0.2526.111-1) ...
Setting up google-chrome-stable (48.0.2564.97-1) ...
Processing triggers for menu (2.1.47) ...
Then just parse it.
The ChromiumDash also makes the data available via an API. You can use that to fetch the latest tag for a platform and a channel.
Eg: https://chromiumdash.appspot.com/fetch_releases?channel=Stable&platform=Windows&num=1
Returns
[
{
"channel": "Stable",
"chromium_main_branch_position": 950365,
"hashes": {
"angle": "343b7bb57268e1cb47da26fcb0ed40fe47e8ff5d",
"chromium": "cab11adacc41ee856c79e669c2fd38d8864e52c4",
"dawn": "1b1b658d365591b6a8d4bfb0c3524832c89afc99",
"devtools": "b6f648d8921ea8be8f2b32c2061fec7503b56610",
"pdfium": "27cabf3dae38d0634a53316da0ad069bf0413495",
"skia": "a6986cd7224f104044fd5bc29cb5f80796d76f5a",
"v8": "db77a493a5595b835655b243202ac0c2fb1898a6",
"webrtc": "a6b138d6b4ef3a5b2c87f899b67f3b5c8dd3c002"
},
"milestone": 98,
"platform": "Windows",
"previous_version": "98.0.4758.81",
"time": 1643754840000,
"version": "98.0.4758.82"
}
]
I'm running p4 interchanges -b my_branch, and I get a ton of results, the first one being a changelist that we integrated a long time ago.
So I try to integrate again, but p4 integrate -b my_branch //...#changelist,#changelist just returns "All revision(s) already integrated".
The only way to unblock this is to do a forced integration (-f in the integrate command) and then simply accept target (-at when resolving), and that works - p4 interchanges then no longer lists this changelist.
But how can Perforce get into this state to begin with? This happened after we've done a bunch of integrating across multiple branches, but I nothing that I'd think would cause a changelist to become "unintegrated" somehow.
This is on a 2014.1 server.
Thank you for specifying your server version.
The 'p4 interchanges' command can give the "All revision(s) already integrated" message with misleading results when cherry-picking is involved.
There is a command line example here:
http://answers.perforce.com/articles/KB_Article/Cherry-Picking-Integrations
You could also be affected by a bug that was patched in 2014.1 listed here in the server release notes:
http://www.perforce.com/perforce/doc.current/user/relnotes.txt
Bugs fixed in 2014.1 PATCH5
#880506 (Bug #71725) **
The istat.mimic.ichanges configurable controls the reporting
of revisions between stream and parent. If set, istat will
not report cherry-picked revisions already present in the target.
The default behavior will report any changes not credited, even
when the content may already be in the target.
If you would like, you can pull the most recent build of the server P4D for your OS from our ftp site: http://ftp.perforce.com/perforce/r14.1/
REFERENCE
http://answers.perforce.com/articles/KB_Article/Integration-Changes-Reporting
I'm having some problem to get a specific Label version for an old tree path (moved, renamed, etc..) in TFS2008.
The problem I have is the following:
I renamed and moved some portion of tree version files and folder and now I'm not able to get a specific version from a specific Label. This Label was applied on the old tree path, and when I get specific version (with overwrite options checked) appear "Not downloaded" on the Latest column and I'm not able to work on the old baseline (labelled files and folder).
There is the way to get specific version in a custom target path?
The TFPT are helpful to do this?
Thanks!
The solution is get specific version Label on the project root, so the old tree version path is proposed.
Nicola Celiento: I was about to post this as new question when I saw your question and answer, which have also worked for me.
I had a branch called $/MyProject/Dev/OldName, which was renamed to $/MyProject/Dev/NewName in May 2015. I now want to get all the files for this branch as of April 2014 (before the branch rename), but I can't work out how to do this. So far I have tried:
Creating a new workspace mapped to $/MyProject/Dev/NewName. Do Get Specific Version on $/MyProject/Dev/NewName, set Type to Date as of April 2014, set Overwrite writeable files and Overwrite all files. This results in the message: "All files are up to date. No files were updated because the requested file versions were previously downloaded. To force an update, use the "Get Specific Version" command with the "Overwrite all...) option checked." This message is odd because it is telling me to do precisely what I have done to get the message! In Source Control Explorer all files have a status of Not downloaded.
From the command line, do a get using the new branch name (does not work - no files in workspace):
C:\Workspace>tf get $/MyProject/Dev/NewName /version:D"2014-04-08 21:00:00" /overwrite /force /recursive
All files are up to date.
From the command line, do a get using the old branch name (also does not work - no files in workspace):
C:\Workspace>tf get $/MyProject/Dev/OldName /version:D"2014-04-08 21:00:00" /overwrite /force /recursive
No appropriate mapping exists for $/MyProject/Dev/OldName.
Changed my workspace to map to the old branch $/MyProject/Dev/OldName, and then repeated the previous get (also does not work - no files in workspace):
C:\Workspace>tf get $/MyProject/Dev/OldName /version:D"2014-04-08 21:00:00" /overwrite /force /recursive
C:\Projects:
Getting OldName
Using View History on individual files, I can see the files definitely existed at April 2014, and I can also see their contents, I just can't get them for that date (but I can get them OK after the branch rename).
Based on Nicola Celiento's answer the solution for me was to Get Specific Version on the root $/MyProject/Dev project. This got all the branches below $/MyProject/Dev, including the old $/MyProject/Dev/OldName that I wanted.