Jump to content


Sambwise's Content

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


By content type

See this member's


Sort by                Order  

#26792 fstat -Oa attributes on newly added files don't show up running from a ch...

Posted by Sambwise on 05 September 2020 - 06:03 PM in APIs

Yup, you'd set it on the Client(?) object before initializing the connection.  (I haven't used the .NET API, but in the C++ API it's the ClientApi object, in the Python API it's the P4 object, etc.)



#26789 Reverting all files in a shelf if they are identical to head

Posted by Sambwise on 02 September 2020 - 08:41 PM in General

Hmm...

p4 -F %depotFile% files @=CHANGE | p4 -x - tag -a -l to-revert
p4 -F "diff2 -q %depotFile%@=CHANGE %depotFile%#head" files @=CHANGE | p4 -F %depotFile% -x - run | p4 -x - labelsync -l to-revert -d
p4 -F %depotFile% files @to-revert | p4 -x - shelve -d -c CHANGE
p4 label -d to-revert
?

Be nice if "p4 diff2" had an -Oi flag that made it only output identical files; then this'd be a one-liner!



#26783 Reverting all files in a shelf if they are identical to head

Posted by Sambwise on 02 September 2020 - 02:44 PM in General

I'd probably do this by a sequence like this:

p4 unshelve -s SHELF
p4 sync ...
p4 resolve -as
p4 revert -a (or p4 diff -sr | p4 -x- revert)
p4 shelve -r -s SHELF

You could also do this by some scripting to directly remove the identical files in the shelf, but it feels more straightforward to me to just use your workspace to do the work of "rebasing" the shelf to the head revision and then using "p4 shelve -r" to replace the shelf with the result.



#26777 fstat -Oa attributes on newly added files don't show up running from a ch...

Posted by Sambwise on 01 September 2020 - 03:07 PM in APIs

Does your script run within the context of the submitting client (i.e. by setting P4CLIENT and P4HOST appropriately to have it spoof the submitting client)?  I don't think fstat shows you pending attributes for other clients, but it should show them for the current client.

C:\Perforce\test\main>p4 fstat -Oa attrib
... depotFile //depot/main/attrib
... clientFile c:\Perforce\test\main\attrib
... isMapped
... action add
... change default
... type text
... actionOwner Samwise
... workRev 1
... openattr-new like this



#26776 Changelist submission trigger

Posted by Sambwise on 01 September 2020 - 03:02 PM in General

  • You want a "change-content" trigger.  At the time the trigger is executed, the changelist will be in a "shelved" state, and you can access the files from most commands via the revision specifier @=CHANGE (where CHANGE is the changelist number, which you can get passed to your script as the %changelist% arg).
  • I think you want the command p4 grep -L -e "COPYRIGHT NOTICE" @=CHANGE



#26775 Moving Perforce folder to new drive

Posted by Sambwise on 01 September 2020 - 02:57 PM in Administration

https://community.pe.../s/article/2556

Stop the server, move the root folder, update P4ROOT to point at the new root folder, start the server.

When you start the server, P4ROOT must match the location you moved the server root to.  That's really all there is to it.  :)



#26774 System for Unreal Engine

Posted by Sambwise on 01 September 2020 - 02:53 PM in Administration

View PostTwist, on 23 August 2020 - 10:03 PM, said:

What operating system (Windows or Linux) works best with Perforce Helix Core Server?

If you're running a large-scale commercial server, I'd say Linux, unhesitatingly.

If you're hosting a personal project, I'd say use whichever you're more comfortable with.  I've seen many posts on this forum from people who have never used Linux before and are trying to set up a Linux server to use for an Unreal project (because some tutorial said to) and consequently struggling with very basic system administration tasks (managing disk space, etc) that would have been trivial on a platform they were familiar with.  So the hypothetical filesystem performance benefits of using Linux (which, tbh, I'm not sure still exist -- the last time I looked at performance benchmarks was more than a decade ago, and Windows has made some strides since then) may not outweigh the hassle, and in any case aren't really a factor with a relatively small server.

Quote

How much storage would all databases take up roughly and how quickly? I am trying to work out if i should get an extra SSD.

The database doesn't grow very quickly; its size is proportionate to the number of files (not the combined size of the actual files) and the number of users.  Unless your project has a very large number of generated files, the database for a project that only has a few people working on it is going to be measured in megabytes rather than gigabytes.

The depot (which can live on a different drive from the database, and does not need to be on a fast SSD because it's accessed much less frequently) is a function of the actual files in your project, including all their revisions.  For an Unreal project this is likely to actually reach a significant size since the art assets are likely to get pretty big.  If you have a rough idea of how big a snapshot of your project is, multiply that by about ten to allow for versioning (and keep in mind that you might want to cap the number of revisions you store for large assets, or plan to upgrade your disk once the average number of versions per file exceeds ten).

Quote

I see in the manual it is recommended that the Journal should be on a different drive to the metadata. I would also need to find a way to connect another drive in case one begins to fill up .

Storing the journal on a different drive is mostly a matter of resiliency, where if the disk holding the database fails completely you want to be able to use the journal to restore it with absolutely zero data loss.  Again, for a small personal project, you may not care that much; assuming you're taking daily backups/checkpoints and storing them offsite (which is trivial in the modern days of commodity cloud storage), you can never lose more than a day of work (which for a five-person project is a much smaller financial loss than a five-thousand-person project), you probably don't have stringent auditing/compliance requirements that require you to ensure a record of every transaction no matter what, and in a worst-case disaster scenario (like, the entire server machine gets destroyed AND you forgot to take any backups ever), the latest content will probably live in someone's workspace, and can just be resubmitted (minus the history).

Being able to handle eventualities like connecting another drive (which you might want to do to expand storage, etc) plus routine maintenance (backups, monitoring, etc) goes back to my earlier recommendation that you run this on a platform you're comfortable with.  :)



#26773 Workspace views of Streams

Posted by Sambwise 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.)



#26745 P4 Reconcile is trying to add ignored files

Posted by Sambwise on 23 August 2020 - 02:55 PM in P4V

Exclude the folder from the client view:

View:
	//depot/... //Scott_LAPTOP-HACFIQTQ_3015/...
	-//depot/CC/Library/... //Scott_LAPTOP-HACFIQTQ_3015/CC/Library/...

The ignore file only works to stop you from adding new files to that folder (and only if it's not overridden by the -I flag).  Excluding files from your client view tells Perforce to treat them like they aren't even part of your workspace.



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

Posted by Sambwise 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.



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

Posted by Sambwise 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?



#26719 change-commit in Python

Posted by Sambwise on 17 August 2020 - 02:39 PM in P4V

Python's official docs are pretty good: https://www.python.o...gettingstarted/

IMO if you have a working script (especially a relatively simple one like this) there's no particular reason to port it to a different language, especially one you aren't already familiar with.



#26716 Make all check in/out of the same user, me

Posted by Sambwise on 14 August 2020 - 02:47 PM in Administration

Yes, setting P4HOST in the config file would be a way to ensure that everywhere that config file goes, the environment looks the same.



#26710 Make all check in/out of the same user, me

Posted by Sambwise on 13 August 2020 - 11:36 PM in Administration

You can clear the Host field, but I don't generally recommend doing that because your workspace will end up in an inconsistent state if you use it from multiple hosts simultaneously.  Setting a Host field helps enforce that you only use it from one host at a time -- it's fine to move a workspace from one host to another (at which point you update the Host field to reflect the move), but then you have to consistently use it from the new one from that point on.

Another option is to just set a P4HOST value that follows you from machine to machine.  (I used to do this when I had a whole bunch of workspaces that I'd migrate when I got a new machine -- it was easier to just set my P4HOST to the name of the old machine than to update 20 client specs).

Quote

Also can I consolidate, all my Administrator and Bhavbhuti records into one?

That's pretty much up to you -- if you consistently use the same username everywhere (as defined by your P4USER setting), then you'll only have one username.  It's as simple as that.  If you don't set P4USER, then it defaults to your login name on the local OS.



#26707 Make all check in/out of the same user, me

Posted by Sambwise on 13 August 2020 - 04:54 PM in Administration

Run "p4 client" and change the "Host" field from "DEVE1" to "Bhav".  That will tell Perforce that your workspace (which used to live on DEVE1) now lives on a client host called "Bhav".



#26702 Make all check in/out of the same user, me

Posted by Sambwise on 12 August 2020 - 03:51 PM in Administration

So you set your user name to "Administrator" and your workspace name to "Bhavbuti" -- this is a little confusing but as long as you use the same names consistently it doesn't really matter what they are.  :)  Could you go to the command line and run "p4 edit <file>" on the file that you were trying to check out in SCC and paste the result you get back?



#26698 P4 extension

Posted by Sambwise on 12 August 2020 - 02:41 PM in Administration

"p4 extension" is a relatively new command (I had no idea it existed until I googled it just now), so you'll need to upgrade to the latest version of the server to be able to use it.



#26697 Make all check in/out of the same user, me

Posted by Sambwise on 12 August 2020 - 02:39 PM in Administration

Can you explain more about how you moved to the new computer?

Did you move your workspace as well as the server?  Is your username the same on the new computer as it was on the old one?



#26687 Recommended number of checkpoints / journals to keep.

Posted by Sambwise on 08 August 2020 - 04:33 PM in Administration

If you want to avoid keeping all your eggs in one basket, that's more about making sure that your backups (i.e. checkpoints and archive backups) live someplace safe (i.e. not on the same disk as your live db, and either multiple physical copies or some sort of highly durable storage solution that has the same effect).  For a small personal server my approach would be to just keep backups in some kind of cloud storage (Dropbox or GDrive or whatever you're already using -- most cloud storage services have pretty good durability guarantees).  For a single-user Perforce server that's only holding source code and maybe a few small binary assets, I doubt storage space would ever be a major consideration.

If storage space is a consideration, keeping old checkpoints/journals is mostly about being able to recover historical data, either for auditing purposes (e.g. if you want to use old journals to debug some specific sequence of events from a month ago to figure out what exactly one of your users did to get their workspace in this state) or to recover from a serious mistake (e.g. someone with admin permission did an obliterate and you want to reverse it).  How far back do you want to be able to go in one of those situations?  That's a function of both (1) how much you care about having that level of control/security and (2) if you DO care, how good you are at monitoring and how long it'll take you to realize that sort of mitigation is something you want to do.

For a server that you are the only one using, and one where you're doing personal projects that don't have legal auditing requirements, you probably don't really care that much.  :)  If you mess up an obliterate, you're almost definitely going to realize your error right away, rather than finding out about it a year later and having to go fetch the tape backups from the cold storage warehouse.



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

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

View Postnessus, 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.



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

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

View Posteddieparker, 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!  :)



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

Posted by Sambwise 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).



#26658 Determining source of an integration when submitting from shelf

Posted by Sambwise on 27 July 2020 - 02:51 PM in Administration

Try "p4 fstat -Or @=SHELF" -- I'm not positive whether it'll show the resolve info for the shelved revision, but that'd be the most likely place to find it.

If that doesn't work, you could temporarily unshelve the change, at which point it's an open file and the usual "p4 resolved" technique will work.



#26650 Fetching/clone from remote

Posted by Sambwise on 26 July 2020 - 02:44 PM in General

The first part of the error is pretty clear -- change 9 edited a file that the origin has deleted, so that edit conflicts with the delete.  In that instance the locally conflicting change is supposed to get kicked aside into a "tangent" depot to make space for the origin change.

Have you set up the permissions/configurables as described here in "p4 help fetch"?

		The -t flag specifies that conflicting changes should be moved to
		a new tangent, as described earlier. The -t flag requires the -r
		flag. The -t flag also requires that an administrator has set
		server.allowrewrite=1. In order to use the -t flag, you must have
		admin access to the files to be fetched.



#26643 Retrieve number of files sync'd to a client

Posted by Sambwise on 24 July 2020 - 05:29 PM in General

For the "p4 have" case you could do:

C:\Perforce\test\python>p4 sizes -s @Samwise-dvcs-1509687817
@Samwise-dvcs-1509687817 42 files 19331 bytes

I don't think there's a way to do the same thing for the "opened" case since there's no revision specifier that'll only match opened files (unless you do something like pipe the opened file list into a label, which would defeat the purpose).