[p4] integrating when destination has been deleted

[Stephen Vance]

David --

Directory versions are unnecessary, also, because of changelists. The 
state of a directory is uniquely determined by the state of the files 
underneath it for all situations except empty directories.

Imagine if, rather than have a branch or delete just automatically 
apply, you had to resolve it and do an "accept theirs" or an "accept 
yours" such that from that point on you would not have to revisit the 
integration and you wouldn't have had to modify a branch spec. 
Integrating an add with "accept theirs" would make the file present and 
with "accept yours" would have the file missing. Integrating a delete 
would make the file missing with "accept theirs" and present with 
"accept yours".

That is the way I believe it should behave, making directory versioning 
unnecessary.

Steve

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.
>
> 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/ .
>
>
>
>