[p4] Wrong (?) base revision integrating back from a child branch

Tony Sweeney sweeney at addr.com
Mon Sep 20 09:18:56 PDT 2004 

Alen Ladavac wrote:

>Hi Tony,
>
>Thanks for your suggestion. We considered doing that (though we just
>manually resolved all conficts in the end), but it is not The Solution.
>  
>
Indeed.  Perhaps I overstated my case. 

>First of all, in this particular case, the second branch has a "no broken
>code" policy as well. Also, doing that while other people keep modifying the
>main branch can lead to a "neverending story". In practice it would usually
>converge after a few cycles, but still sounds like a Sisyphean task.
>  
>
A compromise solution would be to set up a branch solely for 
integration, either at development branch creation (main -> dev_integ -> 
dev), so that there is a "natural" integration path, or separately, from 
either main or dev, with indirect integration from the other codeline.  
This answers your first objection, since the integration branch would 
not be constrained by the policies of main or dev.  As to main (or dev) 
being a moving target, that's a fact of life, but can be mitigated in 
various ways (insist on developers working in feature branches with 
relatively infrequent integrations to main, lock codelines for 
"integration days").   I second Noel Yap's suggestion to read Appleton 
et al. Here's the link to save you googling:

http://www.cmcrossroads.com/bradapp/acme/branching/branch-creation.html

Tony.

>Alen
>
>
>----- Original Message -----
>From: "Tony Sweeney" <sweeney at addr.com>
>To: "Alen Ladavac" <alenl-ml at croteam.com>
>Cc: <perforce-user at perforce.com>
>Sent: Monday, September 20, 2004 12:44
>Subject: Re: [p4] Wrong (?) base revision integrating back from a child
>branch
>
>
>  
>
>>Alen Ladavac wrote:
>>
>>    
>>
>>>Thanks Steve. I was reading Technote 57, but it doesn't mention the dirty
>>>merges. You explanation clears it up.
>>>
>>>Now, this raises a question about our submit policy. We have a policy
>>>      
>>>
>that
>  
>
>>>no code may be submitted, unless it compiles and works correctly. If we
>>>      
>>>
>want
>  
>
>>>to prevent having problems like this one, it seems that we should
>>>immediately check in all files after an integration. But it collides with
>>>the submit policy, because larger integrations (like this one) usually
>>>cannot even compile without at least some corrections. Neither having to
>>>      
>>>
>do
>  
>
>>>all integration resolving, nor sumbitting non-working code sound
>>>      
>>>
>attractive.
>  
>
>>>Is there some way around this?
>>>
>>>
>>>      
>>>
>>Say you have two branches, dev and main.  You have a bunch of new stuff
>>in dev that is known to compile and test OK in dev.  The  idea is to
>>integrate these changes into main.  However, there's other work in main
>>that may cause your stuff to break, and main has a 'no broken code'
>>checkin policy.   Superficially,  there's a  catch-22 --  you won't
>>know  whether the dev stuff breaks  until  you  check it in. The
>>solution is to turn the problem on its head and integrate from main to
>>dev first.  dev now has the same set of files as if you'd gone the other
>>way, and any breakage will show up in dev and can be fixed in there,
>>where policy is a little sloppier.  Once it again compiles and tests
>>cleanly in dev (depending on how long this takes, you may need to
>>integrate from main more than once), you can integrate back to main with
>>a high degree of confidence that all will be well, since the resulting
>>set of files in main should identically match those in dev.
>>
>>Tony.
>>
>>    
>>
>>>Thanks,
>>>Alen
>>>
>>>
>>>----- Original Message -----
>>>From: "Stephen Vance" <steve at vance.com>
>>>To: "Alen Ladavac" <alenl-ml at croteam.com>; <perforce-user at perforce.com>
>>>Sent: Friday, September 17, 2004 19:41
>>>Subject: Re: [p4] Wrong (?) base revision integrating back from a child
>>>branch
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>It's because of the edits you did before you checked it in.  If you
>>>>downgrade an integrate to an add by performing a 'p4 edit' you create
>>>>what's considered a dirty merge.  Perforce can no longer make some
>>>>assumptions about the integration that it could make with a clean merge
>>>>        
>>>>
>so
>  
>
>>>>it takes you back to the base that it can make those assumptions about.
>>>>
>>>>Steve
>>>>
>>>>At 02:07 PM 9/17/2004, Alen Ladavac wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi List,
>>>>>
>>>>>Just had a situation that I cannot really explain...
>>>>>
>>>>>1) we branch //depot/A/foo.cpp#7 into //depot/B/foo.cpp#1, adding some
>>>>>changes to it (B/foo.cpp#1) in the same time
>>>>>2) then some edits happen to A/foo.cpp resulting in A/foo.cpp#8
>>>>>3) A/foo.cpp gets integrated into B/foo.cpp, resulting in B/foo.cpp#2.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>This
>>>
>>>
>>>      
>>>
>>>>>is only integration (no edits) and it is "accept yours"
>>>>>4) B/foo.cpp is integrated back into A/foo.cpp
>>>>>
>>>>>Now, here is the strange thing. I would expect this last integration to
>>>>>
>>>>>
>>>>>          
>>>>>
>>>have
>>>
>>>
>>>      
>>>
>>>>>A/foo.cpp#8 for base, because it was already integrated into B/foo.cpp.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>But
>>>
>>>
>>>      
>>>
>>>>>no, the server chooses to use A/foo.cpp#7 for base, resulting in a very
>>>>>frustrated programer having to manually resolve about a hundred files
>>>>>
>>>>>
>>>>>          
>>>>>
>>>(this
>>>
>>>
>>>      
>>>
>>>>>one is just an example) that he already resolved when going from A to
>>>>>          
>>>>>
>B.
>  
>
>>>>>Can anyone elighten me as to what are we doing wrong here? Is there any
>>>>>
>>>>>
>>>>>          
>>>>>
>>>way
>>>
>>>
>>>      
>>>
>>>>>to explain to the server that changes that were already considered by
>>>>>
>>>>>
>>>>>          
>>>>>
>>>branch
>>>
>>>
>>>      
>>>
>>>>>B don't need to be reconsidered when moving back from B to A. I mean,
>>>>>          
>>>>>
>any
>  
>
>>>>>other way than simply doing "accept theirs", because we wouldn't want
>>>>>          
>>>>>
>to
>  
>
>>>>>lose changes that were done in branch A, but were not integrated into
>>>>>
>>>>>
>>>>>          
>>>>>
>>>branch
>>>
>>>
>>>      
>>>
>>>>>B yet.
>>>>>
>>>>>Thanks a lot in advance....
>>>>>
>>>>>Alen
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>perforce-user mailing list  -  perforce-user at perforce.com
>>>>>http://maillist.perforce.com/mailman/listinfo/perforce-user
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>Stephen Vance
>>>>mailto:steve at vance.com
>>>>http://www.vance.com/
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>perforce-user mailing list  -  perforce-user at perforce.com
>>>http://maillist.perforce.com/mailman/listinfo/perforce-user
>>>
>>>
>>>
>>>
>>>      
>>>
>>--
>>quis custodiet ipsos custodes -- Juvenal VI 347-8
>>
>>
>>    
>>
>
>
>  
>


-- 
quis custodiet ipsos custodes -- Juvenal VI 347-8

More information about the perforce-user mailing list