Transfer halts if all the files from the changelist have been obliterated about p4transfer HOT 4 CLOSED

Interesting point. Possibly related - a queston about +Sn revisions. Will have a look.

from p4transfer.

Hi @fhautekeete - can you include an excerpt of log file around the obliterated changes. Feel free to santize filenames and paths etc.

from p4transfer.

Hello Rob. This issue can be closed because I found out later that the obliterated files were not the culprit.

Long story short: the transfer failed before because the server disk ran full (it was actually storing to /archives instead of /root). I resolved the problem and later got the 'No files to submit.' I didn't tie the two together because the changelist contained obliterated files. What actually was happening is that the files were pending to be submitted and P4Transfer added all of them again (and since they were already added it thought it had 0 files to submit). As soon as I manually performed the submit P4Transfer was able to continue.

@rcowham Where can we add feature requests? I am looking for functionality similar to P4Transfer but to be able to transfer the current state every X changelists (or after a fixed time interval e.g. weekly) without having all the changelists in between. There is too much data/too many changes to keep up with everything in between but it would be great to be able to transfer snapshots at specific time intervals or every 1000 submissions. The idea is to keep a vendor branch somehow in sync (and hence we can't have any server settings changes (e.g. remote depot setup) on the remote end). DVCS is not an option due to different server platforms.

from p4transfer.

Thanks for update. There have been changes to revert all currently opened files - which would resolve this particular problem.
I tested obliterates and if all files are obliterated, then the changelist would not show up anyway as one to be transferred!

from p4transfer.