## Sambwise's Content

There have been 242 items by Sambwise (Search limited from 29-October 19)

#### See this member's

Sort by                Order

### #25932Writeable flag for typemap folder not working

Posted by on 11 February 2020 - 03:44 PM in General

The typemap is applied to new files at the time you open them with "p4 add"; it won't retroactively change existing ones, and it can be overridden with the "-t" flag.  To change existing files you have two options:

p4 edit -t +w //depot/mystream/UnrealEditor/...
p4 submit -d "Changing type to writable."


This will add a new revision with the +w type; once people sync this down the files will be made writable.  I recommend this first approach because it's the most straightforward.

Second approach:

p4 retype -t +w //depot/mystream/UnrealEditor/...

This will retroactively change all the existing revisions to +w.  This requires admin permission, and the change won't be reflected automatically on sync (since as far as the clients are concerned they already have these revisions) until either a new revision is submitted or clients do something like sync to #none and then re-sync.

### #26773Workspace views of Streams

Posted by on 01 September 2020 - 02:18 PM in Streams

If you want your own unique view of the depot, that view needs to exist somewhere -- in a "classic" model it's in your workspace (which is unique anyway), and in a "stream" model the view is the stream spec (which can be shared between arbitrarily many workspaces that want the same view).  So if each individual user wants their own view, then in a stream model it means they each have their own stream.

Note that just working on your own files doesn't necessarily mean that you need a view which maps only those files; you can just avoid syncing the files you don't want to work on!  (In a classic model I'd typically map the entire depot and just sync the files I wanted.)

### #26728Windows knows the file is in the directory; P4V doesn't

Posted by on 18 August 2020 - 04:08 PM in P4V

If it shows up in P4V eventually, as opposed to being absent because of some kind of filtering, then it sounds like it's a bug in P4V's refresh logic.

### #26724Windows knows the file is in the directory; P4V doesn't

Posted by on 17 August 2020 - 08:00 PM in P4V

Do you have any filters defined in the workspace tab?

Does the file show up in the native shell (Explorer etc)?

What happens if you "p4 add" it from the command line?

### #25926Why is it bad to backup db files?

Posted by on 10 February 2020 - 05:11 PM in Administration

Checkpointing has some nice benefits over snapshotting the raw db.* files:

1. The fact that the checkpoint has to walk the entire the database gives you some assurance that the files are structurally sound.
2. The creation of the new checkpoint is synchronized with a rotation of the journal file, making it easy to recover transactions that happen in between checkpoints.
3. The checkpoint itself is both smaller and more portable than a db file backup.

None of the above are must-haves; you could verify your db snapshot offline, you could manage the journal rotation yourself (or parse out the timestamps during a recovery), portability doesn't matter unless/until you need to move your server, and disks are relatively cheap.  Checkpointing is all in all the most user-friendly way to make db recovery easy, though, as long as you can live with however much downtime it takes to create a checkpoint.

### #26537Why does p4 describe on a shelf show "no files" while unshelving the...

Posted by on 29 June 2020 - 03:02 PM in General

You can combine multiple flags.  Using both "-s" and "-S" together should get you what you're looking for.

### #26532Why does p4 describe on a shelf show "no files" while unshelving the...

Posted by on 26 June 2020 - 07:10 PM in General

engr.vns, on 26 June 2020 - 04:52 PM, said:

Thanks but the cmd I had used with p4 describe was "-s" and not "-S"
I cross-checked again...

Yes, that's why it didn't show any shelved files.    You must use the "-S" flag to show shelved files.

### #26527Why does p4 describe on a shelf show "no files" while unshelving the...

Posted by on 25 June 2020 - 07:56 PM in General

From "p4 help describe":

		The -s flag omits the diffs of files that were updated.

The -S flag lists files that are shelved for the specified changelist
and displays diffs of the files against their previous revision.
If the change is restricted, the description is displayed according
to the rules for shelved restricted changes described above.

Flags are case-sensitive; make sure you're using the -S (that's capital S) flag to show shelved files.

### #26361Why do some files get reported as ignored by "p4 resolved" during int...

Posted by on 30 May 2020 - 02:39 PM in General

"Ignored" means that the revisions that you integrated (i.e. the ones on the project1 side) were ignored.  If you did the resolve with -as this means that the contents of those revisions were redundant -- maybe the revisions were "empty" (i.e. no change) or maybe those changes were already in project2 (e.g. they had already been propagated between the two branches via some path that didn't confer integration credit).

Since an "ignore" causes the target file to ignore the source file, it's expected that diffing the target and source afterwards would show a difference (contrast to a "copy", where the target becomes a copy of the source).  The diff that would be more instructive would be to diff the source revision range:

p4 diff2 project1/file#2 project1/file#4

(given a source revision range of project1/file#3,#4 as in your example)

Or, better yet, diff project1/file#4 against the exact base revision, which you can get by adding the "-o" flag to the "p4 resolved" command.  (The base revision is probably in fact project1/file#2, but not necessarily, depending on the history of the two files.)

Whatever diff you see there was the "theirs" leg of the diff in the resolve.  Diffing the base against project2/file will show you the "yours" leg of the diff.  What you should find is that the "theirs" leg was a subset of the "yours" leg, i.e. it was either empty or it only contained lines that were already present in the target.

All of that is pretty straightforward and is more or less guaranteed to be true just based on the way that resolve -as works; p4 resolve in and of itself is a very simple beast and always comes down to the same calculation of "base vs theirs vs yours".

Further contextual questions may present themselves based on what you find in the diffs, e.g. "why were these diffs already in the target?", "why were these empty revisions created?", "why did that base get selected?", etc.    The answers to those root-cause questions (assuming you care that much) will lie in your file history and may require deeper investigation using p4 annotate, p4 filelog, etc.

### #26370Why do some files get reported as ignored by "p4 resolved" during int...

Posted by on 01 June 2020 - 09:09 PM in General

This is one of the rare examples I can think of where a "resolve -at" would get you an "ignored" record:

C:\Perforce\test\delete>p4 resolve -at
c:\Perforce\test\delete\bar - vs //stream/main/delete/foo#1,#2
c:\Perforce\test\delete\bar - resolving delete from //stream/main/delete/foo#2,#3
//Samwise-dvcs-1509687817/delete/bar - ignored //stream/main/delete/foo
//Samwise-dvcs-1509687817/delete/bar - delete from //stream/main/delete/foo

C:\Perforce\test\delete>p4 resolved
c:\Perforce\test\delete\bar - ignored //stream/main/delete/foo#1,#2
c:\Perforce\test\delete\bar - delete from //stream/main/delete/foo#2,#3
c:\Perforce\test\delete\bar - resolved delete from //stream/main/delete/foo#2,#3

As far as I can think of, though, this would only ever happen in a case where there were multiple resolves, and one completely overrides the other (e.g. it's not possible for a file to simultaneously be a delete and be a copy of a non-deleted revision, so if one is accepted then the other is retroactively ignored).  I can't think of a way for it to happen with a simple one-to-one integrate.

### #26367Why do some files get reported as ignored by "p4 resolved" during int...

Posted by on 01 June 2020 - 07:09 AM in General

Could you re-do all of that and copy+paste the complete command line transcript?  It doesn't make sense that you'd see an "ignored" after doing a "resolve -at", unless something unusual was going on that would hopefully be reflected in some of the command output.

Note that if you do "integ -f", "resolve -as" and "resolve -am" are no longer trustworthy (you can easily lose changes if you do "integ -f" followed by any sort of automerge, since "-f" disables all the base selection smarts) -- but since you're doing a "resolve -at" you should generally get a "copy" regardless.  The only exception would be if the copy was overridden by some other resolve action (which, again, would show up in the output -- you might see additional information during "resolve", or multiple "resolved" records).

The fact that you felt the need to force the integration "to be safe" also suggests that something is missing from the narrative here -- maybe the changes were already merged?  Under the situation you described, there would be no need to "force" the integration.

### #26379Why do some files get reported as ignored by "p4 resolved" during int...

Posted by on 03 June 2020 - 01:16 PM in General

engr.vns, on 03 June 2020 - 05:20 AM, said:

Clarification to tie any loose ends here -
Does the order of the inclusion and exclusion in the branch spec make a difference on integration...

branch spec1:

branch spec2:

The contents of both what's included and excluded is the same but the ordering is different.
Does this make a difference on integration?
How would p4 reconcile the order in case of complex situations...

Later lines override higher ones for any namespaces where they overlap.  In the case of branch2, the exclusion has no effect because it's entirely overridden by the line after it.  In branch1, dir2 is excluded from the mapping.

In all cases, any given path can only be mapped to one place (or noplace) by a particular branch view.  The last line that maps a particular path always takes precedence.  The mapping is bidirectional (reversible), so in cases where paths are mapped differently on different lines, this rule applies to both sides of the view equally (i.e. if a given mapping is overridden when you integrate" forwards", it's overridden when you integrate "backwards" as well).

### #26539Why do files end up with open records of pending integrations even after reso...

Posted by on 29 June 2020 - 03:10 PM in General

Quote

sc unshelve -s <shelf> //This should open up the files for edit and and overwrite the integration with changes from the shelf.
sc revert -a //... //Revert any unchanged files in projectR

Again check that there is nothing to resolve and submits it...(Clxxx)

This sounds wrong.  If the shelf contains files that are already open (in this case they'd be open for integrate), a resolve should be required to merge the shelf's changes with the pending changes in the workspace.

If you wanted to make sure that the thing you just submitted includes the shelved changes, you could "p4 diff" vs the shelved revision before submitting (or for that matter "p4 diff -f" or "p4 diff2" after submitting).

Quote

To cross-check that everything is clean, the user in a new client refreshes the WA (which includes the changes he submitted earlier) and re-unshelves the same shelf..

What's a WA?  ("Work Area", i.e. workspace?)  Does "refresh" include syncing the head revision?

This workflow makes no sense, because the changes have already been submitted.  Why unshelve an old version of the changes to "cross-check" them?  After submitting the changes from a shelf, you'd usually just delete the shelf.  Syncing the submitted revision should be all you need to do to get those changes.

Run "p4 resolve -n" to see what it is that needs resolve.  I could make some guesses, but there's a lot that I don't know about what the user is doing.  It sounds like they may have opened the files before doing the unshelve, in which case they'd need to resolve the shelf vs their workspace in order to get those changes.  This does not explain why the changes wouldn't have been pulled down by a sync (unless the files were also open prior to the sync, in which case the sync itself would also schedule resolves for those files, so nothing would modify the workspace copies but you'd end up with two pending resolves per file that each contain the same changes), but I also don't actually know whether they even did a sync in the first place.  Too many variables to cover!

Quote

Is the method to override the some of the integration with changes from the shelf the issue...?

Combining the copy with the unshelved changes (which could include anything) is definitely a potential source of complexity -- it in theory should all work, but if something goes wrong it's a lot harder to decipher the history when you have multiple operations mushed into one revision.  If at all possible I'd do the copy first, submit it, and THEN do the unshelve rather than squashing the two operations into one changelist.

### #26598Why are these files left open for delete even after resolve

Posted by on 14 July 2020 - 02:01 AM in General

"revert -a" only reverts unchanged files.  You want just regular "p4 revert //..." if you want to revert everything.

### #25745What's the suggested P4API for developing custom tool on MacOS

Posted by on 17 December 2019 - 04:06 PM in APIs

It depends on the tool.  If it's running a simple p4 command, you don't need any API beyond the CLI tool.  If it's something more complex but nothing graphical, I'd write a Python script using P4Python.  If it's a graphical tool where I needed to use Cocoa, I'd write it in Obj C (ugh) and use the C++ API.

### #26673What does the number in the p4 -I sync -q ... output mean?

Posted by on 01 August 2020 - 06:10 PM in General

I wasn't sure, but a quick test confirms that it is indeed the number of files:

C:\Perforce\test>p4 sync #none | wc -l
3

C:\Perforce\test>p4 -I sync -q ...
... 3 finishing


It goes by too fast in my test case to actually see progress, but I assume with more data you see that number increase from 0 to whatever the full count is.  I think the idea is that if you want to gauge progress as a percentage, you'd preview the sync first with "-n" to get the total (that's what the UI does IIRC).

### #26680What does the number in the p4 -I sync -q ... output mean?

Posted by on 05 August 2020 - 06:31 AM in General

eddieparker, on 04 August 2020 - 07:05 PM, said:

Thanks for verifying.  Is this forum a good place to offer feedback suggestions?  I wish that information was already in the print-out versus having to do a p4 sync -n first, and that seems generally useful.

If you want feedback implemented in the official build I think you have to submit that through support@perforce.com.

For features in the command line client it's actually pretty easy to just roll them yourself as long as you're okay with doing your own builds.  The approach I'd suggest taking would be to implement your CLI sync progress bar as a client-side command (similar to "p4 set" or "p4 tickets") that invokes the appropriate server commands and formats the data the way you want it.  A good example of this sort of extension is "px" which is a custom version of p4 that adds extra options and commands: https://swarm.worksh...shawn_hladky/px  The "p4 undo" command was available in px as "p4 rollback" almost ten years before it was implemented in the server!

### #25712Using git as an emergency backup?

Posted by on 09 December 2019 - 05:20 AM in General

benchang, on 08 December 2019 - 06:57 PM, said:

I have P4 admin privileges but not filesystem-level access so I don't think there's much I can do on my own.

As an admin you can reclaim disk space by obliterating files, but this will only be effective if you have large files that are unnecessary (e.g. if somebody's been submitting giant binary files to the Perforce server).  If:

1) this disk is dedicated to the Perforce server
2) it filled up very suddenly
3) you don't have any limits in place to prevent users from submitting giant files

it's very possible that one student has (unwittingly?) denial-of-serviced the Perforce server by submitting enough data to it to fill up the disk.  You could do a quick check of the student directories (I assume you've got permissions set up so that each student is at least confined to a particular part of the depot) to see if any of them are abnormally large.  Here's an example of a query like that run against the //guest depot on public.perforce.com:1666:

% p4 -F %dirName%/... dirs "//guest/*" | p4 -x - sizes -s
...
//guest/yael_stern/... 53 files 574669 bytes
//guest/yariv_sheizaf/... 118 files 400574 bytes
//guest/ydatoor/... 15 files 523797 bytes
//guest/yonas_jongkind/... 155 files 3769823 bytes
//guest/zach_helke/... 1 files 3133 bytes
//guest/zachwhaley/... 42 files 54005 bytes
//guest/zardlove/... 1 files 16 bytes
//guest/zynthar/... 405 files 159849886 bytes



If one user seems to be taking up all the space, you can go into their directory and obliterate whatever seems superfluous.

If the disk isn't dedicated to the Perforce server, or if it's been creeping up for a while and nobody noticed until it hit the failure point, those are both good things to raise to the IT department as fixable problems.

Quote

If they do this, would it work to use their existing P4 workspace directory also as their local git repository, so that when the helix server is back online they can sync the changes?  Or would it be safer to have them just use a clean directory for their git repository?

Using the workspace directly is fine, but they should make sure to exclude the .git directory from their workspace (or add it to their P4IGNORE file) since they probably don't want to add git's repo metadata to the Perforce depot.

Note also that students should be able to simply clone personal Perforce servers on their own machines.  That way when the central server comes online they'll be able to push their local history to it directly (whereas if it's in git it's probably not going to be easy to convert back into Perforce).

https://www.perforce...f/p4_clone.html

If the clone command still fails with the disk space error, a temporary workaround would be to bump down the filesys.P4LOG.min configurable (obviously you only have 250M worth of wiggle room, so this is not a long term solution; you might want to disable write access until the root cause is resolved).

### #25565Using a Broker to route traffic based on depot paths?

Posted by on 06 November 2019 - 05:54 PM in Administration

Redirecting every command in such a way as to make usage seamless seems like a lot more difficulty than it can possibly be worth.  I think the strategy you want to pursue is education-based rather than trying to hide the change -- make sure users who are looking for these depots know where to find them.  This could be as simple as putting empty depots in those spots with a README inside them.  If you want to get really fancy, maybe a broker filter on specific commands like "p4 fstat //old_depot/*" that will produce an error message (with the new server info) which will display as soon as a user tries to navigate to that depot?

Miles O, on 06 November 2019 - 05:04 PM, said:

Why do you want to do split these depots out?

Actually, yes, this too.  If you're splitting them out for performance reasons but you want to hide that from the user, might something like commit/edge fit the bill?

### #25783user-resolve failed

Posted by on 01 January 2020 - 06:05 PM in Administration

If it's missing from the rev table rather than the working table, opening it for edit won't fix it.  I think the error in that case might be due to one of the source files being obliterated out from under you.

The best path forward is probably going to be to revert (use the -k flag if you want to preserve local changes) and then re-open the file for whatever you were doing.  If you were integrating and some revisions of the source (or the base) got obliterated while you were resolving, you'll want to re-run integrate so it can figure out what needs to be merged (if anything) out of whatever's left and what the new best base revision is.  If it was a normal edit and a revision you were resolving against got obliterated, you might not need to do anything at all other than re-open it (although you should double-check your diff to make sure it still makes sense and doesn't include any changes that were supposed to have been obliterated).

### #25974[Solved] How to detect p4 edit failed in a batch file?

Posted by on 19 February 2020 - 07:54 PM in General

Some years ago I started a collection of all the little one-liners I was able to run from CMD without needing an actual scripting language.  The main thing all of them have in common is that they don't have any branching conditions (i.e. they don't need to take different actions based on the result of a given command):  https://swarm.worksh...s/oneliners.txt

There's also this one, which I used on a very regular basis before "p4 grep" existed: https://swarm.worksh...ipts/p4find.bat

Luckily all of that cut/sed stuff was eventually obsoleted by the "-F" flag.    https://web.archive..../fun-formatting

### #25970[Solved] How to detect p4 edit failed in a batch file?

Posted by on 19 February 2020 - 03:34 PM in General

My approach is usually to define success criteria rather than check for specific errors, e.g. run a "p4 opened FILE" and check that I get a message confirming that the file is open.  There are a lot of reasons that a "p4 edit" might not open a file, with different levels of "severity" as defined by the server, but they're all fatal errors if you expect a file to be open and one didn't get opened.

### #25972[Solved] How to detect p4 edit failed in a batch file?

Posted by on 19 February 2020 - 06:06 PM in General

yeah... it almost goes without saying that I don't do anything more than a couple of lines long in a batch file.  If that were a requirement I'd probably compile my own version of the p4 command line with arcane global flags that let me map specific message codes to specific exit values (one can envision a flag that says "treat any message of severity greater than E_INFO as a fatal error", or "any message that's not the specific 'opened for edit' message", etc).

Realistically I've generally used Perl for most Perforce scripting, using regexes to grab specific messages.  Nowadays I'd probably use P4Python.

### #26681[P4Python] which command supports P4.Progress?

Posted by on 05 August 2020 - 06:44 AM in APIs

nessus, on 01 May 2020 - 07:05 AM, said:

Are sync and submit the only two commands that support progress?

Yes and no.

Sync and submit are the only commands that support the Progress API as far as I know.

However, most p4 commands return their output one file at a time, even if they don't use the progress API, so if you're handling the output programmatically you can take advantage of that to build in the concept of progress tracking.

If you're willing to delve into the guts of the C++ client library implementation and make custom modifications to it, you could do some pretty fine-grained progress tracking for a command like "p4 diff -sd" (which might do a lot of work in between lines of output) by adding logic to the clientCheckFile function.  Run "p4 -vrpc=3 diff -sd" to get an idea of how this function works -- it's invoked for each file but it only prints output (via a server response) if the file is missing, so you could measure progress by the number of clientCheckFiles that have happened relative to the number of files in the client.

### #26464[ASK] P4V rollback from paid license to free license

Posted by on 18 June 2020 - 04:25 PM in Administration

Unless the licensing has changed at some point in the last few years, you should be able to continue using your current license in perpetuity as long as you don't upgrade the server to a newer version (as long as it's a paid license and not a temporary/eval license, which have more of a 'hard' expiration policy).

If you want to switch to the "unlicensed" version so you can continue to upgrade (beware that this puts you at the mercy of future changes to how many users are allowed by the unlicensed server), you can test this out by renaming your license file (so it's no longer recognized by the server) and then restarting the server.  If you're over the unlicensed limit, the server will refuse to start (and you can recover by putting the license file back).