Jump to content


"Get These Revisions" of changelist with 1 file caused syncing 100,000 files


  • Please log in to reply
9 replies to this topic

#1 mikecline

mikecline

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 26 July 2018 - 05:19 PM

I frequently use the “Get These Revisions” option in the Submitted Changelist view to cherry pick a small change that someone else has checked in when i know the change is fairly independent of other changes.  This is a huge time saver since a full sync and build can take 30-40 minutes in our environment.

Also when checking in a small fix I will recommend to others on the team to use "Get These Revisions" as a way of quickly getting my fix without having to incur the 30-40 minute penalty of a full sync and build.

Yesterday I checked in a change to one file, and went to a coworker's machine, found my change in the Submitted Changes window, right clicked on it and did "Get These Revisions" and a progress bar appeared showing that it was syncing over 100,000 files.  I quickly cancelled, but it left his machine in a bad state for the rest of the afternoon eventually requiring a heavy-hammer, force resync of the entire project.  I was horrified that what should have been a 30 second sync and build wasted so much time.

Perhaps I misunderstood what "Get These Revisions" meant.  The only docs I could find about this online simply say:

To get the revision of all files in the changelist, right-click the changelist and choose Get These Revisions.


My mental model is that it would be equivalent to right clicking on each of the files within the changelist, going to the history view, right clicking on the revision of that file which that CL brought the file up to, and doing "Get this Revision".  So I don't understand how it's possible that this operation on a 1-file changelist could have caused many files to sync.   I have also heard anecdotal, yet vague, references from other members of the team of the Get These Revisions feature wreaking havoc.

Why would "Get These Revisions" of a 1-file changelist sync 100,000 files?
If this is not the recommended way of getting "just the revisions of just the files in the changelist" then what is?

#2 mikecline

mikecline

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 27 July 2018 - 05:03 PM

I also polled the rest of the team for their experiences with this feature, here's an anecdote from one other developer.

It’s good to know that I’m no longer alone in this. I’ve used the feature on a number of occasions to no peril, but one time, without prompt, it caused Perforce to delete every file from my harddrive that was in the project, forcing me to force-get the entire project and rebuild. I have no clue what I did differently that time but it’s left me hypersensitive to Perforce operations since.



#3 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 667 posts

Posted 27 July 2018 - 05:52 PM

The next time you see it happen, I'd look at the P4V log pane to see what command it ran.  Sounds like there's a bug where it's not building the arguments  correctly?

#4 mikecline

mikecline

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 27 July 2018 - 06:20 PM

I discovered how to reproduce this problem.

The behaviour of this context menu option is different depending on whether you are doing it from the Submitted tab versus the History tab.  Doing it from the History tab is the one that starts messing with crazy numbers of files (it's actually deleting them, not syncing)

When right clicking on CL 531167 from the Submitted tab and doing "Get These Revisions" I get:
p4 sync -f --parallel=0 @531167,@531167
This output of this command shows two files being "refreshed" -- the two files in the changelist.

When right clicking on my project's name in the depot tree and then right clicking CL 5311167 in the History tab, and donig "Get These Revisions" I get:
p4 sync -f --parallel=0 //depot/MyProjectName/...@531176

The output of this command shows many hundreds and thousands of files being deleted, with each output line in the format
//depot/MyProjectName/Path/To/Some/File deleted D:/Project/MyProjectName\Path\To\Some\File


Also, for what it is worth, other members on the team suggested that they find it more trustworthy to use Get Revisions…” --> “Only get revisions for files listed in changelist”, which issues a separate sync for each specific path in the changelist:
p4 sync -f --parallel=0 //depot/MyProjectName/Path/To/Some/File@531167,@531167 {1 more items}


Questions:
  • Why should "Get These Revisions" behave differently between the History Tab and the Submitted changes tab?  This is totally unintuitive.
  • Why does syncing
    //depot/MyProjectName/...@531176
    cause it to start deleting massive numbers of files whereas syncing
    @531167,@531167
    seem to behave fine?
In my perfect world, I think "Get These Revisions" ought to behave identical to "Get Revisions"->"Only get revisions for files listed in changelist", but just be a faster shortcut for the same.

#5 mikecline

mikecline

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 27 July 2018 - 08:44 PM

Perhaps this is a bug and the developers intended the version in the history tab to do

p4 sync -f --parallel=0 //depot/MyProjectName/...@531176,@531176

instead of what it does now

p4 sync -f --parallel=0 //depot/MyProjectName/...@531176

I did some command line testing with "p4 sync -n -f" around this (preview the operation without actually executing).  If using some more specific path like so

p4 sync -f --parallel=0 //depot/MyProjectName/Some/Specific/Path...@531176

it will touch every file in /Some/Specific/Path regardless if CL 531176 contains any changes which affect /Some/Specific/Path.  (This includes playing back a whole bunch of deletes of every location that every file in that directory used to be, which I think explains why I was seeing so many delete operations when doing this on a broader scope)

Whereas if you use the syntax that I presume was intended:

p4 sync -f --parallel=0 //depot/MyProjectName/Some/Specific/Path...@531176,@531176

it would sync only the files in that specific CL which are also in /Some/Specific/Path.

Even if I'm correct about the intention, I don't really see the benefit of reducing the scope of the sync operation to just the folder that is currently selected.  It would be better to just "p4 sync -f --parallel=0 @531167,@531167" just as the submitted changes window does.  Most people, most of the time are not going to want to get half a changelist, as that tends to cause problems.  (or if you insist that this is useful, and the CL in question contains files outside of the restricted scope, it could pop up another question dialog where you can choose  "all files from 531167" vs. "only files from 531167 that are under /Some/Specific/Path")

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 667 posts

Posted 27 July 2018 - 08:44 PM

P4V's behavior is frequently an enigma to me, but this at least I can answer:

View Postmikecline, on 27 July 2018 - 06:20 PM, said:

Questions:
  • Why does syncing
    //depot/MyProjectName/...@531176
    cause it to start deleting massive numbers of files whereas syncing
    @531167,@531167
    seem to behave fine?

The first command will sync *all* files in the named path to the revision that existed as of change 531176.  For most commands, when you use a single revision specifier like @CHANGE it's specifying the end of a range, with the implied beginning of the range being @1 (and for a command like sync, you then get the latest revision that falls within that range) -- hence all files will be affected, including files that did not exist yet as of that time (they will be deleted).

The second command uses a much narrower range that both starts and ends (inclusively) with change 531176, so it will only match the revisions that were created as part of change 531176.

If that doesn't make sense, compare the output of these three commands:

p4 files //depot/MyProjectName/...@531176
p4 files //depot/MyProjectName/...@1,@531176
p4 files //depot/MyProjectName/...@531176,@531176


#7 mikecline

mikecline

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 01 August 2018 - 08:07 PM

For anyone following this thread, I emailed the issue separately to Perforce Technical Support.   The issue has been raised as a bug report internally.

#8 p4rfong

p4rfong

    Advanced Member

  • Staff Moderators
  • 293 posts

Posted 20 August 2018 - 05:06 PM

Thanks for reporting this! This was a indeed bug that has since been fixed in job095971.  Expect to see it fixed in the next version of P4V.

#9 mikecline

mikecline

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 04 September 2018 - 03:56 PM

That is fantastic, thanks for fixing!
What is the exact fix?
does the history window now do this?  

p4 sync -f --parallel=0 //depot/MyProjectName/...@531176,@531176

or something different?

#10 p4rfong

p4rfong

    Advanced Member

  • Staff Moderators
  • 293 posts

Posted 13 September 2018 - 07:57 PM

We removed "Get These Revsions" item from the context menu.

We removed 'previous' checkbox and added a 'previous  Revisions' context menu to submitted changelists.

We changed 'Get These Revisions' to 'Get Revisions in Changeslist XXXXX'




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users