Jump to content


Putting head revision into source files


  • Please log in to reply
11 replies to this topic

#1 Groover

Groover

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 28 October 2019 - 04:46 PM

I am porting a project from subversion. I have a command line utility called subwcrev that gets the head revision number for the entire project and replaces any occurence of $WCREV$ in a source file with the version number. This allows me to display the revision number to the user for bug reporting, etc.

How can I replicate this with Perforce?

Example:

namespace Foo
{
	public static class Revision
	{
		public const int REV = $WCREV$;
		public const String REVSTR = "$WCREV$";
	}
}


Thanks!

#2 P4Adam

P4Adam

    Advanced Member

  • Staff Moderators
  • 6 posts

Posted 29 October 2019 - 10:30 AM

Hi Groover.

If you mark a file as needing 'keyword expansion', keywords in that file will be automatically replaced with the appropriate change number, revision number, author, timestamp and a few other keywords.
Doc'd here:

https://www.perforce...etypes.rcs.html

Note that the keyword would relate to the file you're referencing; I'm not sure how this matches your "head revision for the entire project".

If that doesn't quite fit, your current utility could open the file for edit, do the replacement, then submit the file once again.

#3 Groover

Groover

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 29 October 2019 - 11:49 AM

Hi Adam, Thanks for responding. The keywords would only change when the file is touched but here I need to know the revsion number for the entire project.

The current utilitity only works on subversion local copies - it will generate an error if the folder structure is not a subversion structure.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 966 posts

Posted 29 October 2019 - 02:35 PM

Sounds like you want the changelist number ($Change), which is essentially the "version number" for the entire repository.

#5 Groover

Groover

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 29 October 2019 - 05:07 PM

View PostSambwise, on 29 October 2019 - 02:35 PM, said:

Sounds like you want the changelist number ($Change), which is essentially the "version number" for the entire repository.

Looks like that expands to "$Change xxx $" which is not a number but a string. I can't put that into an assembly version for example. Also the docs says that the value is updated "whenever a file is committed to the repository" but if that particular file doesn't change then it won't be updated, right?

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 966 posts

Posted 29 October 2019 - 07:12 PM

Here's a cheesy way that I've done this in the past:

https://swarm.worksh...reeabout.h#view

I'd just make sure to update that file (and submit it) before I made a new build, and then the version number would automatically get compiled into the build via the keyword expansion.

If you want to write a script to run as part of your build/deployment rather than using keyword expansion, you can just fetch the change number directly from Perforce with the "p4 changes -m1" command.

#7 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 191 posts
  • LocationSan Francisco, CA

Posted 29 October 2019 - 11:04 PM

Just wanted to directly iterate that Perforce has no concept of 'version of entire project'. It's verify file-centric. Each file has its own revisions and changelist numbers independent of each other.

However, the highest changelist number of a branch is usually enough to identify the code in the entirety of it.

Syncing, say, to //some/path/...@change insinuates //some/path/...@0,@change, the range starting at the beginning of time and ending with the designated changelist (which itself can be thought of as a moment in time.)

I've seen many ways to convey this to an end user, or a build robot. One of our current methods is to have the build robot check in a file named something like 'version.h' that has the changelist number keyword expanded into it, then use that as the basis of the build. Folks that you provide the code to would need to be trained to look only in _that_ file for the correct build reference, not _any_ file.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#8 Groover

Groover

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 30 October 2019 - 01:35 PM

That only works if version.h is changed. If it's a trivial file that doesn't need changing then the value in that file won't be changed. If the user has to remember to touch it to force an update then that opens up the risk of the user forgetting.

I suppose there may be a clever way of running a batch file during build to touch the file but then what if the user forgot to check that file out.

I tried p4 changes -m1 etc and this produces output that I could parse with a custom utility, but unless I am mistaken, I can't run this command line from a custom utility because I would need to pass login credentials every 12 hours and there isn't a command line switch to specify the password. Right? Subversion stores the changelist version in the local copy metadata so running svnwcrev doesn't require a username or password or a need to talk to the server - it just extracts it from it's local metadata.

With subversion we never release anything outside of the company without applying a unique number to that release, allowing us and the recipient to always know what we have given and what they have on disk. A number for a single file isn't too useful because files don't live in isolation - we need to be able to reference an entire project in one go. This is made trivial with the svnwcrev utility.

#9 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 966 posts

Posted 30 October 2019 - 03:20 PM

View PostGroover, on 30 October 2019 - 01:35 PM, said:

I tried p4 changes -m1 etc and this produces output that I could parse with a custom utility, but unless I am mistaken, I can't run this command line from a custom utility because I would need to pass login credentials every 12 hours and there isn't a command line switch to specify the password. Right?

No, scripting Perforce is pretty easy.  :)

If the command is running from the same environment where the user is submitting or working on their files, it'll just inherit their credentials (i.e. any script the user runs in their environment will just run as them, the same way it'll inherit filesystem permissions etc).

If you're running this as part of some centralized automation, the standard (reasonably secure) solution is to use a dedicated Perforce user account (historically Perforce would give you a free license to use for things like this, I'm not sure if that's still the case), and give that user an unlimited login timeout so you can just login once on that machine (which is presumably more secure than the average laptop -- the automation user can also be locked down to only have read-only access if that makes sense).

The standard INsecure solutions (which are a little easier but also aren't recommended) are:
  • don't set a password on that user (this is the hilariously insecure option, only works if the server doesn't mandate passwords)
  • do p4 -P PASSWORD changes -m1 (this works if you're on a server that doesn't mandate that you use login tickets)
  • do echo PASSWORD|p4 login (this works on a "secure" server, but is still terrible practice from a security standpoint)

(edit: wait -- how do you even do builds in the first place if you don't have a script that has permission to sync the files from Perforce?  :blink: )

#10 Groover

Groover

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 31 October 2019 - 07:29 PM

Deleted

#11 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 191 posts
  • LocationSan Francisco, CA

Posted 05 November 2019 - 07:10 AM

View PostSambwise, on 30 October 2019 - 03:20 PM, said:

If you're running this as part of some centralized automation, the standard (reasonably secure) solution is to use a dedicated Perforce user account (historically Perforce would give you a free license to use for things like this, I'm not sure if that's still the case), and give that user an unlimited login timeout so you can just login once on that machine (which is presumably more secure than the average laptop -- the automation user can also be locked down to only have read-only access if that makes sense).

Or do what we also sometimes do, 'p4 login -p' with the password being in a secure parameter in our build system, then use that ticket for the duration of the build. This also has the wonderful (not wonderful) side effect of having your logs fill up with thousands of 'p4 logins' every day.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#12 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 191 posts
  • LocationSan Francisco, CA

Posted 05 November 2019 - 07:12 AM

View PostGroover, on 30 October 2019 - 01:35 PM, said:

That only works if version.h is changed. If it's a trivial file that doesn't need changing then the value in that file won't be changed. If the user has to remember to touch it to force an update then that opens up the risk of the user forgetting.

In some cases the build bot checks that file in. In other cases we (sloppily) have a trigger that checks it in right after a user checks is other files in the path, with the trigger user being the only one that can write to the version.h file.

I don't always design these things, I just implement them. :)
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users