[p4] Confused by 'p4 integrate' behavior.

[steve@vance.com]

Actually, David, there are a couple of good places for that information.
The integed table could record the relationship like it already does. The
revision history also has that possibility, as I alluded to in my post.

Let's take the example of a file that was added in a child branch and
you're resolving the integrate back to the parent. If you don't want to
propogate the add, then you do an 'accept yours' and the integrate record
is an 'ignore from'. You can create a revision at the current target as a
placeholder in the changelist by creating a head revision that is a delete
revision. You really are submitting the choice to not have a visible file
at that location.

If you deleted the file in the target branch, then just add another delete
revision.

That should cover it in the framework already established by Perforce.

Steve

Original Message:
-----------------
From: Weintraub, David david.weintraub at bofasecurities.com
Date: 	Wed, 04 Oct 2006 08:21:58 -0400
To: steve at vance.com, kk at kozminski.com, perforce-user at perforce.com
Subject: RE: [p4] Confused by 'p4 integrate' behavior.


The problem is that there is no place in the current Perforce database
to store these decisions. For example, what if I have a file in my
source branch, but not my target branch? Let's say this happened because
I deleted that file from my target branch. The first time through, I
somehow tell Perforce "Do not add this file to my target branch". Where
does Perforce store this information? It can't store it in the target
file because there is no file in my target branch. That's why we
manually have to modify the branchspec to store this information.

Maybe what we may need is an "internal branchspec". That is, when we
tell Perforce "don't add this file", this internal branchspec could keep
track that we don't want to add this file. Then, Perforce will know the
next time not to attempt to delete or add this file.

In fact, if this internal branchspec could be versioned like a file, it
could even anticipate our responses. Let's take the missing file in my
target branch. This could be for one of two reasons (okay, there's more
than two, but we'll consider two for now): I could have removed the file
from my target branch or I could have added the file to my source
branch.

Let's take the first case, and say I removed the file from my target
branch. Perforce would examine the internal branchspec, see that there
is a new version of this branchspec since the last integration, and see
that this file was deleted. It could then know, without even asking me,
that I don't want this file readded when I again integrate from the
source branch to the target branch.

Let's take the second case, and I added the file to my source branch.
Perforce would examine the branchspec, see that the file was never in my
target branch, and ask if I want to add the file. When I say "no",
Perforce would track that decision in the internal branchspec, create a
new version of the internal branchspec with that decision, and never ask
me again.

All we are now missing is a way to move files and be able to track the
move. Right now, we actually do a copy and delete which isn't quite the
same. Let's say we actually have a "move/rename" command:

    $ p4 mv foo.cpp bar.cpp

Now, my internal branchspec can actually track the move (just like you
would with your current branchspec). Next time I integrate, my internal
branchspec will let the integrate command know that the file foo.cpp in
my source branch should integrate with file bar.cpp in my target branch.

Would this work?

-----Original Message-----
From: Stephen Vance [mailto:steve at vance.com] 
Sent: Tuesday, October 03, 2006 4:19 PM
To: Weintraub, David
Cc: Krzysztof Kozminski; perforce-user at perforce.com
Subject: Re: [p4] Confused by 'p4 integrate' behavior.

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


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .