[p4] integrating when destination has been deleted

Wed Aug 30 17:31:50 PDT 2006

Weintraub, David wrote:
> The problem isn't that Perforce doesn't track directories (which it does
> by making the directory an attribute of the file). Perforce doesn't
> track directory versions. For example, I do my integration:
>
>    $ p4 integrate //depot/Proj/MAIN/... //depot/Proj/REL_1.0/...
>
> Perforce tells me it wants to add a file
> //depot/Proj/REL_1.0/Foobar/foo.cpp because this file is in MAIN, but
> isn't in REL_1.0. Well, I deleted this file because it wasn't needed. No
> problem, I'll just revert it, and finish up.
>
> A few days later, I want the latest changes on MAIN into REL_1.0, so I
> do this again...
>
>    $ p4 integrate //depot/Proj/MAIN/... //depot/Proj/REL_1.0/...
>
> Again, Perforce tells me it wants to add a file
> //depot/Proj/REL_1.0/Foobar/foo.cpp because this is in MAIN, but not
> in REL_1.0. Poor Perforce can't tell if //depot/Proj/MAIN/Foobar/foo.cpp
> is a newly added file, which is why I don't have it in my branch, or a
> file I specifically deleted from my branch. Every time I do my
> integrate, Perforce will ask.
>   
Wait a minute, Perforce _does_ know that 
//depot/Proj/MAIN/Foobar/foo.cpp is a file that you specifically deleted 
from your branch. It's still in the depot, with a head revision of 
"deleted". What Steve said makes more sense. Perhaps Perforce can handle 
this without any real major change.

You all have convinced me that this is a shortcoming in Perforce. 
Manually keeping up the branchspec with this information doesn't seem 
right. A branchspec is just a lump of text, really, and is not stored or 
consulted when commands use integration history. In other words, a 
branchspec is not the place to store this information; it would be 
better kept as part of the integration records (somehow).

> That's why I have to create and *MANUALLY* modify the branch
> specification to handle these file deletions in the integrate process.
>
> The only real way around this particular problem is for Perforce to make
> directories full members of the depot and to version directories like
> Subversion and ClearCase do. That way, Perforce knows that
> //depot/Proj/REL_1.0/Foobar/foo.cpp was deleted, and won't ask me to
> create it again. I wouldn't have to modify my Branch spec.
>
> -----Original Message-----
> From: steve at vance.com [mailto:steve at vance.com] 
> Sent: Wednesday, August 30, 2006 4:03 PM
> To: Weintraub, David; medellre at yahoo.com; perforce-user at perforce.com
> Subject: Re: [p4] integrating when destination has been deleted
>
> I would argue that since deleted revisions are still revisions of the
> file, that the problem could be solved if Perforce added accept
> yours/theirs semantics for adds and deletes. It shouldn't require any
> major changes, including directory knowledge.
>
> Steve
>
> Original Message:
> -----------------
> From: Weintraub, David david.weintraub at bofasecurities.com
> Date: 	Wed, 30 Aug 2006 11:39:49 -0400
> To: medellre at yahoo.com, perforce-user at perforce.com
> Subject: Re: [p4] integrating when destination has been deleted
>
>
> Ahh... The one of the problem due to Perforce not tracking directories.
> In ClearCase, when you merge from one branch to another, ClearCase first
> does a "directory merge" then does an actual file merge. That way, if
> you delete a file in the merge target, ClearCase won't attempt to merge
> the missing source file to the target directory.
>
> The problem is that Perforce doesn't operate on directories, so it can
> never understand this type of action. To Perforce, there's a file in
> "REL_1.0.0" that doesn't exist in "REL_1.1.0", it needs to be added to
> "REL_1.1.0".
>
> This is one of the few instances where Branch Specifications do come in
> handy. Let's say that //depot/Proj/REL_1.0.0/Foobar/foo.java and
> //depot/Proj/REL_1.0.0/Foobar/bar.java where deleted in the REL_1.1.0
> branch, you could setup a branch specification like this:
>
> Branch: rel_1.1.0
>
> Description:
>     For Integrating between Rel 1.0.0 and Rel 1.1.0
>
> Options: locked
>
> View:
> 	//depot/Proj/REL_1.0.0/...  //rel_1.1.0/Proj/REL_1.1.0/...
> 	-//depot/Proj/REL_1.0.0/Foobar/foo.java
> //depot/Proj/REL_1.1.0/Foobar/foo.java
> 	-//depot/Proj/REL_1.0.0/Foobar/bar.java
> //depot/Proj/REL_1.1.0/Foobar/bar.java
>
> Now, when you run the command:
>
>    $ p4 integrate -b rel_1.1.0
>
> It will no longer attempt to integrate foo.java and bar.java from
> REL_1.0.0 to REL_1.1.0. Now, the developer won't get the spurious
> warnings about needing to integrate obsolete files, and when they do run
> the integration command, they won't be forced to deal with Perforce's
> insistence that these files should be added.
>
> By the way, this is all explained in Laura Wingard's book "Practical
> Perforce" (Chapter 4 Branching and Integrating - Reconciling Structural
> Changes). I recommend that all Perforce administrators get this book. I
> wish I had it before I set up this site. It would have saved me a lot of
> headaches.
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Rene Medellin
> Sent: Wednesday, August 30, 2006 9:48 AM
> To: perforce-user at perforce.com
> Subject: [p4] integrating when destination has been deleted
>
> hi,
>
> i have the following scenario:
>
> 1) developer edits a class in //depot/project/1.0.0 branch.
>
> 2) branches 1.1.0 and 1.2.0 exist downstream from 1.0.0
>
> 3) i have a night script that i run that iterates through the downstream
> branches looking for pending integrations. it sends a nice reminder to
> developers to deal with their integrations.
>
> 4) developer claims that the classes modified in 1.0.0 have been already
> deleted in 1.1.0 and subsequent releases so they don't "need" to be
> integrated. i tell them that that may be so but when running 'p4
> integrate -b 1.1.0' p4's branch consistency check still requires those
> files be integrated forward (so to speak). after resolve, they can just
> delete them again.
>
> 5) developer grumbles that she'll need to continue to make changes to
> 1.0.0 for some time and that she'll have to keep doing this
> integrate-resolve-delete dance in all the downstream branches until
> 1.0.0 no longer needs to be maintained.
>
> any suggestions for how else to handle this?
>
> thanks,
>
> Rene Medellin
> marketaxess.com
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at http://mail2web.com/ .
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   