Jump to content


Move and integrations

move integrate

  • Please log in to reply
6 replies to this topic

#1 mob

mob

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 22 February 2019 - 08:11 AM

Hello,

we had issues with move and integrations.
Let's say the original tree was like this:

//DEPOT/project/configuration

This was integrated from //DEPOT/project/... to //DEPOT/nextproject/...

Now on the new branch the directory is moved from //DEPOT/nextproject/configuration to //DEPOT/nextproject/custom/configuration.

Making changes on old  //DEPOT/project/configuration
and re-integrating //DEPOT/project/... to //DEPOT/nextproject/... does not merge the changes from the old location to the new moved location. For this situation we need to do specific integrations like from //DEPOT/project/configuration/... to //DEPOT/nextproject/custom/configuration/...

But the integrator usually doesn't know about all the moves and like Perforce to care about the mapping to new locations.
Otherwise every p4 move would mean to modify a Branch Specification accordingly which needs far more maintenance.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 917 posts

Posted 22 February 2019 - 11:01 AM

View Postmob, on 22 February 2019 - 08:11 AM, said:

Making changes on old  //DEPOT/project/configuration
and re-integrating //DEPOT/project/... to //DEPOT/nextproject/... does not merge the changes from the old location to the new moved location.

It should.  Did you do the move in nextproject with the standard "move" command, or did you do some kind of manual branch+delete thing?

#3 mob

mob

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 22 February 2019 - 11:07 AM

It was a real p4 move. Would that also work over several branch integrations or does this also require populate -f?

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 917 posts

Posted 22 February 2019 - 11:10 AM

In the scenario you describe there are only two branches.  If you're doing something trickier you'll need to go into a little more detail for me to understand why it wouldn't be working and suggest how to improve the workflow.  Here's a quick reconstruction of your scenario as given, showing how the integrate works without any special adjustment:

C:\Perforce\test\mob>p4 filelog ...
//depot/nextproject/custom/configuration
... #1 change 115 move/add on 2019/02/22 by Samwise@Samwise-dvcs-1509687817 (text) 'foo'
... ... moved from //depot/nextproject/configuration#1
//depot/nextproject/configuration
... #1 change 114 branch on 2019/02/22 by Samwise@Samwise-dvcs-1509687817 (text) 'foo'
... ... moved into //depot/nextproject/custom/configuration#1
... ... branch from //depot/project/configuration#1
//depot/project/configuration
... #2 change 116 edit on 2019/02/22 by Samwise@Samwise-dvcs-1509687817 (text) 'foo'
... #1 change 113 add on 2019/02/22 by Samwise@Samwise-dvcs-1509687817 (text) 'foo'
... ... branch into //depot/nextproject/configuration#1

C:\Perforce\test\mob>p4 integ project/... nextproject/...
//depot/nextproject/custom/configuration#1 - integrate from //depot/project/configuration#2 (remapped from //depot/nextproject/configuration)

C:\Perforce\test\mob>p4 resolve -as
c:\Perforce\test\mob\nextproject\custom\configuration - merging //depot/project/configuration#2
Diff chunks: 0 yours + 1 theirs + 0 both + 0 conflicting
//Samwise-dvcs-1509687817/mob/nextproject/custom/configuration - copy from //depot/project/configuration
c:\Perforce\test\mob\nextproject\custom\configuration - resolving move to //depot/nextproject/configuration
//Samwise-dvcs-1509687817/mob/nextproject/custom/configuration - ignored //depot/nextproject/configuration

C:\Perforce\test\mob>p4 submit -d tada
Submitting change 117.
Locking 1 files ...
integrate //depot/nextproject/custom/configuration#2
Change 117 submitted.

Note that the "p4 integ" automatically adjusts the mapping so that project/configuration maps into nextproject/custom/configuration.  It also sets up a filename resolve where the default action is to ignore the difference rather than propagate it, so that the final result of a "p4 resolve -as" is to copy the edit in the source while keeping the move in the target.

My guess is that if you are doing some kind of complex sibling-merge workflow that's not captured by the above example and you're hitting an edge case with moves, "populate -f" won't be a good workaround (in fact it might make things worse -- I forget now what it does with move/deletes but if it does copy them that's not a good thing in this case) and you'll need to do a more mainline-style workflow to make it work 100% of the time.

(edit) oh good, I did already think of that, lol:
	#1408304 **
		'p4 copy -f' and 'p4 populate -f' will no longer copy 'move/delete'
		source revisions into nonexistent targets as new 'delete' revisions.


#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 917 posts

Posted 22 February 2019 - 11:28 PM

<p>I remember now that I wrote a blog article a while back on the perils of combining refactoring (i.e. moving lots of stuff around within a branch) with reparenting (i.e. moving your branch relationships around) that discusses the problem in some depth and gives some workarounds:

https://www.perforce...and-reparenting

The "experimental features" described at the end of that article didn't get any further than the implementation of this configurable:

dm.copy.movewarn 0 verbose 'p4 copy' warnings for moved files

If this option is on AND you create your branches by "p4 copy" (rather than "populate" or "integrate"), it'll analyze the branch creation to let you know if there are moves in the source whose history is not being reflected in the new target revisions, and it'll tell you what earlier changelist you could branch from in order to provide a basis for that history -- so you'd do the copy from that changelist, submit, and then do another copy at the head rev (which will now create new revisions on top, including the appropriate deletes and move/deletes with all the right connecting history).  The idea was that from there it'd be possible to automate a "deep branching" workflow where when you created a branch you'd create it with multiple changelists as needed to provide history for merges from arbitrarily distant downstream branches.

#6 mob

mob

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 03 April 2019 - 09:30 AM

We don't use streams yet. In your blog you start with the old workaround of branch specs, then move over to using streams. So is this only possible with streams? I mean when 2 branches have different directory trees after one of them has moved stuff, and some magic branch spec is updated in the background in order to keep the files on different directories mapped when integrating between the 2 branches?

#7 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 917 posts

Posted 03 April 2019 - 02:48 PM

Nope, this works the same exact way with classic branches.  Take a careful look at the example I posted earlier, where I show the history of the files (which corresponds exactly to the specific example you described with "configuration", "custom/configuration", "project", and "nextproject") and how an integrate automatically adjusts itself to account for the "moved from" in that history.  No stream specs are involved.

All of that automatic adjustment happens dynamically for each individual file, on top of whatever mapping was used to start the integration (regardless of whether it was two file paths at the command line, a branch spec, or a stream view).

It's also subject to the same limitations in terms of needing reference points in the history of the source and/or target to figure out how to do the adjustment.  If the rename happened completely in some third location then it can't be mapped through the view that relates the source to the target.  In the example that view is "project/... nextproject/..." so if the rename happened in "someotherproject" instead of "nextproject" as you described, then the example wouldn't work, similarly to what's described in that blog post.





Also tagged with one or more of these keywords: move, integrate

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users