Jump to content


Sambwise

Member Since 12 Sep 2016
Offline Last Active Today, 01:58 AM
*****

Posts I've Made

In Topic: Refresh existing workspaces to respect updated typemap

05 April 2020 - 09:35 PM

View Postsubressor, on 05 April 2020 - 08:10 PM, said:

Thanks! I'm pretty sure I tried that and got some weird error like 'client name not recognised' or something.

Sounds like you didn't have a client spec set up.  Any time you're operating on local files (so like when you're opening them for edit, or even when you're referring to files by a local relative path), the client spec defines how your local files correspond to the depot files.  If you got the error I'm thinking of, it actually tells you exactly how to fix it!

C:\Perforce\test>p4 files ...
Client 'subressors-computer' unknown - use 'client' command to create it.

If I already had a client spec set up on this computer, I could switch to it by running "p4 set P4CLIENT=that-client-name", but the error message is telling me that I can create a new client spec with the "client" command.  Thanks for that tip, error message!  Let me try that...

C:\Perforce\test>p4 client

This brings up my text editor with my new client spec:

Client: subressors-computer

Owner: subressor

Description:
Created by subressor

Root: c:\Perforce\test

Options: noallwrite noclobber nocompress unlocked nomodtime normdir

SubmitOptions: submitunchanged

LineEnd: local

View:
//depot/... //subressors-computer/...

The important parts of the client spec are the "Root" (which says where the client spec lives -- it defaults to my current directory) and the "View" (which says how the depot relates to the client root -- by default the entire depot is mapped, or all depots if you have more than one).


If I save this file and exit the editor, it saves the client spec:

C:\Perforce\test>p4 client
Client subressors-computer saved.


Now I can run commands on files in my local directory!  The client spec says that whenever I'm in C:\Perforce\test using this client spec on this computer, it's the same as being in //depot on the server.


C:\Perforce\test>p4 files ...
//depot/foo/bleh#1 - branch change 147 (text)
//depot/main/bleh#1 - branch change 148 (text)


Quote

Do you know if there's any way to use retype on specific file formats in specific areas of the depot? Or is retype only to be used generally or on certain files

I would recommend using the "p4 edit" method; "p4 retype" is not something that's meant for general or routine use.

Any command that operates on files can take a wildcard pattern -- in my previous post you saw how I used the pattern "b..." to say "open all files whose paths relative to this directory start with b for edit with the type of binary".  You could also do "....txt" to say "all files under this directory that end in .txt", or "//depot/foo/....jpg" to say "all files that are in the //depot/foo directory whose names end in .jpg", or any combination you can imagine.

In Topic: Refresh existing workspaces to respect updated typemap

03 April 2020 - 04:54 PM

View Postsubressor, on 03 April 2020 - 04:12 PM, said:

p4 retype help worked, but almost every combination I put in thereafter seemed to give me a failure message of some description. I tried it with the whole depot, file area, an individual file. I can't remember exactly what the errors said, should have screenied it but it was late and I was loosing motivation :/

Having the error message and knowing what commands you used would make it possible to debug.  Any time you're trying to get remote help from someone (whether it's professional tech support or some rando on the Internet) it's very important to keep track of what you did and what happened so you can relay it to the other person!  :)

Here's what it looks like when it's working -- in my example I want to change everything in my current directory (all the files currently have the type "text") to the type "text+k":

C:\Perforce\test\main>p4 files ...
//stream/main/main/bar#1 - add change 149 (text)
//stream/main/main/baz#1 - add change 149 (text)
//stream/main/main/foo#1 - add change 149 (text)

C:\Perforce\test\main>p4 retype -t text+k ...
//stream/main/main/bar#1 - text now text+k
//stream/main/main/baz#1 - text now text+k
//stream/main/main/foo#1 - text now text+k

C:\Perforce\test\main>p4 files ...
//stream/main/main/bar#1 - add change 149 (text+k)
//stream/main/main/baz#1 - add change 149 (text+k)
//stream/main/main/foo#1 - add change 149 (text+k)

Note that I'm just running the "p4 files" commands to show what files are there and what their current types are.

If I wanted to change their type via "p4 edit" (let's say this time I want to make the files that start with "b" the "binary" filetype), here's how that looks:


C:\Perforce\test\main>p4 edit -t binary b...
//stream/main/main/bar#1 - opened for edit
//stream/main/main/baz#1 - opened for edit

C:\Perforce\test\main>p4 submit -d "Changing the B files to binary"
Submitting change 150.
Locking 2 files ...
edit //stream/main/main/bar#2
edit //stream/main/main/baz#2
Change 150 submitted.

C:\Perforce\test\main>p4 files ...
//stream/main/main/bar#2 - edit change 150 (binary)
//stream/main/main/baz#2 - edit change 150 (binary)
//stream/main/main/foo#1 - add change 149 (text+k)

For what it's worth, I typically recommend using the "p4 edit" method unless you have a very compelling reason to use "retype" instead, because I think it's generally preferable to have all of your changes be versioned rather than to have them apply retroactively.

In Topic: Lost my Depot - Help!

03 April 2020 - 02:17 PM

View Postsubressor, on 03 April 2020 - 10:15 AM, said:

I did some linux navigation and found that the depot name was at the root of the drive ( /depot/...). But I found 3 'collections' of db.* files...

That suggests that maybe you started up the server with a P4ROOT of "/" (the literal system root), which is not great for obvious reasons.  

Quote

It looked like the depot was owned by 'root' user, not by the 'perforce' user I had set up to own/run the p4d instance.

That makes sense, since only root would be allowed to write files directly into the system root directory.  You must have logged in as root before running "p4d", and done so in the system root directory.  Instead you'd want to log in as the "perforce" user before running p4d (and probably also set p4d up to run as a cronjob under the "perforce" user so you wouldn't have to start it manually).

Quote

It took a lot of closing/opening putty because every time you start the server, it says 'perforce server starting' and locks the terminal so that you can't do anything else...

Opening multiple terminals is fine.  You can also tell p4d to run in the background by using the "-d" (for "daemon") flag, or by using the shell's "&" operator which tells it to fork the process (this works for any command where you want it to keep doing its thing while you get your terminal back).


Quote

Finally, after getting the correct instance running in the right place by the root user, I then tried signing in from my client but it kept asking for my password endlessly (which
was the initial reason why I restarted the server!).

To be honest I'd just recommend against using P4Admin, because that sounds like buggy client behavior, and IMO server administration is adequately simple from the command line that it's not worth wrestling with a GUI.

Quote

Now I'm trying to copy the files I already have on my computer to my newly mapped work-space and ask perforce to recognise/link them to the depot instead of downloading the whole thing again...

If you've set up a new server and want to add the contents of your old workspace to it, you can do that without copying any files around.  Just create a workspace for the new server that's in the same location as the one you used for the old server (note that you wouldn't want to do this for two different servers you're using at the same time, but since this is your one and only server it's fine to just port your old client environment over to it).  Then "add" all the files and "submit" them, easy peasy.

cd C:\my_workspace\folder
p4 client
p4 add ...
p4 submit -d "Ta da!"

In Topic: Refresh existing workspaces to respect updated typemap

03 April 2020 - 02:09 PM

View Postsubressor, on 03 April 2020 - 10:05 AM, said:

I tried fruitlessly, but unfortunately I couldn't get it to work...

I'm pretty sure either "retype" or "edit" is the correct command to use.  What exactly did you try, and what didn't work?

In Topic: p4 integrate - Visual comparison and integration between 2 projects

02 April 2020 - 07:24 PM

View Postengr.vns, on 02 April 2020 - 06:19 PM, said:

But this methods are not visual and atomic.
It would be easier visually compare and merge the directory tree similar when you are doing selective integration.

I'm not at all clear on what you mean by "visual and atomic".  Could you give an example of a problem you're hitting when you use either of these methods that reflects the lack of visibility and/or atomicity?

Quote

Is there a visual method to -

STEP 1) directory or file compare between projects on two different depots.
STEP 2) Integrate it visually in the GUI


In terms of directory compare, P4V has a "folder diff" feature that's very useful.  Similarly, you can integrate in the GUI, although I'm not clear on exactly what visuals you're after; the GUI doesn't offer a lot of visualization for the actual process of opening files for integrate, but I'm not sure what sort of value it would be able to add.  Usually the thing that's important to visualize is the actual per-file merge (which can be visualized through P4Merge whether you're using P4V or the CLI).