Occasionally I use Windows Command Prompt to change the name of a file in PVCS since that way the file will retain its history, however, I've been trying to rename about a dozen documents and after a few file changes PVCS will disconnect from the server we have it on. We then restart the server, and then once again, after a few file changes, run in to the same problem. This only seems to happen when I'm using Windows Command to change file names.
Are these two things, in fact, related? If so, is there anything that can be done to prevent this?
Please advise. Thank you.
Accepted Answer0I second Gerard's request. Kindly indicate as well which VM release you are running on the client doing the renaming and on the VM File Server.
If the rename feature has been enabled, VM 8.6 lets you rename a file directly from command line using a single PCLI command. Example:
C:\>pcli Rename -prC:\ProgramData\Serena\vm\SampleDB -idroot -nshutdown_renamed.txt /chess/server/shutdown.txt
Serena PVCS Version Manager (PCLI) v18.104.22.168 (Build 370) for Windows/x86_64
Copyright (C) 1985-2017 Serena Software. All rights reserved.
Searching for shared archives: 96 file(s) processed, 0 found. Currently checking /chess/server/shutdown.txt...
Searching for shared archives completed: 18102 files processed, 0 found.
/chess/server/shutdown.txt: Renamed to shutdown_renamed.txt. Archive C:\ProgramData\Serena\VM\SampleDB\archives\chess\server\shutdown.txt-arc renamed to shutdown_renamed.txt-arc.
Accepted AnswerJennifer SOffline
Accepted Answer0I do the following under 8.5.x.x:
vcs -w"[new document name.docx]" "[old document name.docx-arc]
vtransfer -r "[old document name.docx-arc]" "[old document name-TEMP.docx-arc]"
vtransfer -r "[old document name-TEMP.docx-arc]" "[new document name.docx-arc]"
I forgot the reason why the vtransfer is done in two steps. I think it's to handle cases where the rename involves just a change in case.
Richard Geringmore than a month ago10 points for Gerard! :) Yes, that is the reason you (potentially) do it in two steps.
Following this, do you use "pcli delete" followed by "pcli importarchives"?
The VM 8.6 Rename command effectively combines this under the hood, without having to delete the entity, plus it deals with updating the shared archives (if you have any). If you know you don't have shared archives to worry about the vcs/vtransfer/delete/importarchives route is faster at this time, though that's something we're hoping to change.
Accepted Answer0Certainly! You need to have the PDB path and entity path to run these commands:
pcli delete -pr"PDB" -id"Credentials" "EntityPathToFile"
pcli importarchives -pr"PDB" -id"Credentials" -pp"EntityPathToProject" "PathToArchive"
For the delete command you could also use the entity path to the project and the name of the file:
pcli delete -pr"PDB" -id"Credentials" -pp"EntityPathToProject" "NameOfFile"
Of course this could all be combined into a single PCLI script that figures out the archive path based on the entity path and runs the vtransfer command(s) as well. I don't have that handy at present but could cook one up for you, if you're interested. I wrote a pre-6.5 archive suffix converter once (renaming archives like makefile.txv to makefile.txt-arc) and it has about 80% of the functionality needed to pull this off. It's surprisingly complex to do well in a generic way, so it works on FS and non-FS alike, and would still have to make assumptions on the PDB archive suffix being the standard +arc and +.-arc pair, as there's no easy way to compute the archive name for a given workfile name for a non-standard ArchiveSuffix directive in PCLI.
VM 8.6's Rename command can do it all, of course ;-)
Gerard Pinzonemore than a month agoWe use Cygwin so we scan use bash scripts to manage things from the command line. I took some time to add the delete and import commands into the bash script and it seems to work. Obviously a PCLI script would be a lot cleaner.
Accepted Answer0Jennifer, the commands you are running are technically okay and I can see no reason why VM would lock up. However, VM 22.214.171.124 does have a number of issues on archive path handling. At minimum you should run 126.96.36.199, though ideally 188.8.131.52 or 184.108.40.206 (which also makes Rename available in the I-Net Web Client and PCLI).
Note that in the VM 8.5.x GUI you can rename a file from the Desktop Client GUI, so you don't have to resort to using command line. See KB doc S106699 for info. Still recommend not running 220.127.116.11, though.
Please let us know what you find. If the disconnecting behavior continues, please open a Support Incident and report the SI number here so we can take this offline and exchange logfiles.