Jump to content


Ran out of space and can't log into workspace!


  • Please log in to reply
38 replies to this topic

#21 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 11 March 2019 - 06:36 PM

Is there a way to see what my typemaps are already?  Whenever I use P4 Typemap, it seems to create a new file.  That doesn't seem right.  Maybe what I've done wasn't saved.  I'll be honest, I don't know much about Linux/Unix.  So I could be screwing something up without knowing it.

#22 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 11 March 2019 - 06:46 PM

When you run "p4 typemap" your editor should open on a text file containing the current typemap.  Make changes there, save the text file, exit the editor.  You should see "Typemap saved." at the command prompt.  If you run "p4 typemap" again, the file that comes up should still have the changes you just made.

It will be a physically different local temp file, but it's populated by the same data from the server so that doesn't matter; it should be the same exact typemap you just saved.

#23 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 11 March 2019 - 06:55 PM

Hmmm...  A TextEdit file pops up when I type P4 typemap.  I make the changes I want, then save the file in TextEdit.  Then I hit Control-Z in the Terminal (because it's just sitting there) an it says... "[3]+  Stopped                 p4 typemap " I then type P4 typemap again and my changes haven't been saved.  I assume I'm messing something up....

#24 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 11 March 2019 - 07:09 PM

Ah -- yeah, you killed the typemap command before it actually saved the typemap to the server.  It's waiting for the editor to exit to know that you're done with the file, and TextEdit doesn't exit when you close the window.  I think you can use TextEdit if you remember to exit the app after you save the file -- or you can run "p4 set P4EDITOR=vim" or some other editor that's more CLI-friendly.

#25 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 11 March 2019 - 07:13 PM

Awesome.  Thanks for the heads up.  I wasn't closing TextEdit (was using it for other things so didn't need to close it after I was done).  

I have a problem, though.

I typed "+S7 //..." on the line under TypeMap in the file.  When I do that (and close everything), it says "Syntax error in '+S7'.

Is there something else that needs to be added to this?

#26 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 11 March 2019 - 07:29 PM

Make sure there's a tab at the start of the line?  Multiline fields in Perforce forms are always tabbed; a line with no leading whitespace marks the start of the next field.

It should look like this (assuming I can convince Invision not to garble the formatting):

TypeMap:
	+S7 //...


#27 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 19 March 2019 - 10:51 PM

Thanks for the tip.  I didn't have the tab at the beginning of the line, but once I put it there, it works fine now.

So I started working on pruning files and started following the information that you posted on Stack Overflow.  When I run the first line...

p4 tag -l minus7 ...#head

It says I'm "not under client's root".  What I don't understand is I figured all of the label stuff was going on with the server and no my local files.  Can you explain a little bit as to why this would be the case?  I'm not sure I want to mess with my local files since my main computer has plenty of space to store whatever.  It's the server that has the problem with space.

I'm not sure if I'm misunderstanding something, though.

#28 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 20 March 2019 - 09:22 PM

Replace the "..." with "//...".

The "..." means "everything mapped to the current local directory".  If you just want everything across the entire server regardless of your client mapping, that's "//...".

#29 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 21 March 2019 - 02:30 AM

Awesome.  I imagine this is true for the "Labelsync" stuff as well?  Like it should be "//...@<minus7"?

Also, in the example I've assumed that the reason the labelsync was used two times is because the person was only saving two versions back.  However, if I wanted to do seven versions back, then I'd need to do labelsync seven times.  I made the tag and that worked great.  I was about to do the other stuff, when I thought I'd clarify before I possibly messed something up.

#30 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 21 March 2019 - 05:53 PM

View PostSambwise, on 28 February 2019 - 10:53 PM, said:

To apply this same technique to keep seven revisions rather than two, just do the labelsync step seven times (to decrement all the revision numbers, one at a time) instead of two times.

Keep in mind that when you're running "labelsync" all you're doing is updating the label you've created, so the cost of failure is low.  If you "mess up", it costs you nothing to just reset the label to #head and start again.  Once you're done manipulating the label, look at its contents with "p4 files @LABEL", or maybe "p4 files FILE@LABEL" to inspect the revision of a particular file that's in the label.  You can do that to validate that it contains everything that you want to get rid of (and nothing that you don't want to get rid of) before you actually do the obliterate (from which there is no return).

E.g. if you have a file called //depot/foo that has only five revisions, running "p4 files //depot/foo@LABEL" after you've done the labelsync-back-seven-times thing should get you "no such files" (which means also that if you obliterate @LABEL, //depot/foo will not get obliterated).  You can do sanity checks like that on specific files that you know should be "safe" to make sure the label has been constructed correctly.

#31 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 25 March 2019 - 10:26 PM

When I try to use "p4 obliterate -y #,@minus7", it says "Missing/wrong number of arguments."  Has something changed that I need to add another argument here?

#32 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 26 March 2019 - 12:51 AM

What happened when you ran the "p4 files -a" with the same file/revision argument to preview it?  (I assume you aren't testing this syntax out for the first time with a live "obliterate -y" where a typo is going to nuke the entire repository...)

#33 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 26 March 2019 - 05:03 PM

View PostSambwise, on 26 March 2019 - 12:51 AM, said:

What happened when you ran the "p4 files -a" with the same file/revision argument to preview it?  (I assume you aren't testing this syntax out for the first time with a live "obliterate -y" where a typo is going to nuke the entire repository...)

When I ran the "p4 files -a" line, it said the same thing..."Missing/wrong number of arguments."  Everything else has worked fine.  I ran the test lines "P4 files @Label" and it worked fine.

Heh, I didn't obliterate anything.  Once it didn't work, I posted it here and didn't try anything else.  I don't want to screw anything up.  :)

#34 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 26 March 2019 - 08:49 PM

And you ran:

p4 files -a "#1,@minus7"


?  Depending on your shell, the double quotes might be necessary to keep the # from being interpreted as a comment -- they shouldn't hurt in any case.

#35 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 26 March 2019 - 10:17 PM

View PostSambwise, on 26 March 2019 - 08:49 PM, said:

And you ran:

p4 files -a "#1,@minus7"


?  Depending on your shell, the double quotes might be necessary to keep the # from being interpreted as a comment -- they shouldn't hurt in any case.

I didn't use quotes because the original link didn't use quotes.  I'll try it again with quotes to see what happens.

#36 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 27 March 2019 - 12:07 AM

Good rule of thumb any time it seems like a command line argument disappeared or has split into multiple pieces is to put quotes around the argument.  Shells generally split arguments on spaces, so an argument that contains a space (e.g. a filename like "C:\Program Files\foo") will generally need to be quoted in order to be considered a single argument, and some shells on Unix consider a "#" to be a comment character, so you need quotes around an argument that contains a comment to keep the # and everything after it from being ignored.  (I mostly used Perforce on Windows, which doesn't do that, but I definitely remember it being a thing sometimes when I was in my Linux VM.)

Good thing you didn't run "p4 obliterate -y //...#1,@something" or you might have obliterated "//..." (which is everything)!

#37 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 27 March 2019 - 12:50 AM

Okay.  That's good to know.  I went ahead and used the correct obliterate command and it seems to have worked.  Going forward, I'll be going back to the P4V client since I now have it set to store only 7 revisions back and deleted some of the excess files.

Something interesting I noticed is that I did purge some files, but when I look at how much space I have on the server, it's the same as it was.  It's like nothing has been deleted.  Does Perforce take a while to actually delete things or is it an instant thing?

#38 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 784 posts

Posted 27 March 2019 - 01:47 PM

It should be an instant thing.  I guess if it's been obliterated it's too late to check now, but it would have been interesting to run "p4 sizes -a -s #1,@minus7" to get the sum of the sizes of all the revisions you were obliterating to see how much space savings to expect.

It could be that your VM host has some sort of delay to register a change in available space, though?  I'd expect a "du" inside the VM to give accurate information but disk usage shown in the VM management tool could well be based on some external metric that takes a while to update.

#39 EDarkness

EDarkness

    Member

  • Members
  • PipPip
  • 20 posts

Posted 28 March 2019 - 12:19 AM

I have no idea.  I checked the size of project and it's the same as it was.  No idea what's going on, but I'll deal right now.  Hopefully going forward it'll avoid keeping more than 7 copies of a file.  I guess we'll see where we're at in a few months now that we can get back to working on the game in a more regular fashion.

Thanks for the help, man.  This whole thing has taken a long time to get solved.  I'm just glad I can continue on.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users