[p4] Confused by 'p4 integrate' behavior.

[Stephen Vance]

Full directory versioning is not necessary to solve this issue. Simple 
ability to accept yours or accept theirs for deletes and adds is 
sufficient. The file-based versioning can be made to handle it without 
all the complexity of directory versioning (e.g. accept yours when 
integrating a branch/add gives a #1 version that is a delete).

The only thing directory versioning solves is the empty directory 
problem. Even rename issues can be solved without that.

Steve

Weintraub, David wrote:
> One of the problems with Perforce is that directories aren't full fledge
> members of your archive. Instead, they're merely "attributes" that are
> attached to each file. Each time Perforce looks at your integration, it
> sees no //depot/x/branchOld/snafu, so it assumes that
> //depot/x/branchNew/snafu should also be removed to keep the two
> branches in sync. There's no way for Perforce to track the idea that
> snafu should be in one branch, but not the other since -- unlike file
> merges and integrations -- this information isn't in the file itself.
>
> If Perforce truly versioned directories as well as files, integrations
> could also be performed on the directories themselves. Perforce could be
> made to understand that the directory version on branchNew has a file in
> it that isn't on the directory version of branchOld, and Perforce would
> stop insisting on deleting snafu on branchNew every time you do your
> integration.
>
> As you discovered, the way to handle this issue is to manually
> manipulate the branchspec. You also have to do this if you rename the
> file on branchNew or moved the file to another directory.
>
> I would personally like true directory versioning -- mainly because I
> come from the ClearCase world and understand how it works. However,
> directory versioning creates other issues that would complicate
> integrations and merges, so I can understand why Perforce chose to avoid
> it.
>
> Directory versioning can create some weird side effects that confuses
> many developers, and that may be the reason why Perforce chose not to
> implement it. I've noticed that Perforce tends to implement things in a
> way that Developers find easier to understand (like interfile branching)
> rather than ways I think as a CM they "should" be implemented.
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Krzysztof
> Kozminski
> Sent: Tuesday, October 03, 2006 5:57 AM
> To: perforce-user at perforce.com
> Subject: [p4] Confused by 'p4 integrate' behavior.
>
> Here's the relevant portion of the history of two files:
>
> % p4 filelog //depot/x/branchNew/snafu
> //depot/x/branchNew/snafu
> ... #1 change 4509 add on 2006/10/03 ...
>
> % p4 filelog //depot/x/branchOld/snafu
> //depot/x/branchOld/snafu
> ... #5 change 4292 delete on 2006/08/31 ...
> ... #4 change 4285 edit on 2006/08/31 ...
> ... #3 change 4278 edit on 2006/08/30 ...
> ... #2 change 4246 edit on 2006/08/25 ...
> ... #1 change 4241 add on 2006/08/25 ...
>
> Relevant info: //depot/x/branchNew was branched off //depot/x/ branchOld
> in change 4506, using this branch specification:
>
>     //depot/x/branchOld/... //depot/x/branchNew/...
>
> and this command:
>
>     p4 integrate -b branchNew -s #have
>
> while portions of branchOld were synced @4500, some portions were @4490,
> and the rest was up-to-date (yes, there was a good reason for that). I
> am positive that snafu was not present in any revision prior to #5.
>
> Now, the confusing part: the integration attempt:
>
> % p4 integrate -n //depot/x/branchOld/... //depot/x/branchNew/...
>
> attempts to delete snafu from branchNew.
>
> It seems to me that given the sequence of events (branchOld/snafu was
> deleted BEFORE branchNew/snafu was added), the integration has no
> business deleting branchNew/snafu.
>
> If branchNew/snafu was branched off some revision < 5 of branchOld/
> snafu, then yes, deletion would be understandable, but not in the
> scenario described above.
>
> Two questions:
>
> 1) Is this supposed to be happening that way? What is the rationale
> here?
>
> 2) How do I tell Perforce to ignore the deletion that happened on
> branchOld, keep the stuff I have in branchNew, and not attempt to delete
> branchNew/snafu? I am looking here for something like 'p4 resolve -ay'
> that would ignore 'their' change (in this case, 'their'  
> deletion). While I can hack a branch specification like this:
>
>     //depot/x/branchOld/... //depot/x/branchNew/...
>     -//depot/x/branchOld/snafu //depot/x/branchNew/snafu
>
> this looks like too much effort for something that should be doable with
> less hassle (I have another 50 files like 'snafu'). Also, if I ever add
> branchOld/snafu again, I would like to get a chance to integrate it
> without having to remember to remove it from the branch specification...
>
> BTW, both client and server are version 2005.1.
>
> KK
> _______________________________________________
> 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
>
>