[p4] p4 interchanges question

Wesley Hunt weshunt at fusemail.com
Tue Oct 9 05:30:30 PDT 2007


I wish partial changes were the culprit. Alas, these changes have only
one file in them, so that cannot be the case. The example illustrated
below I reproduced easily in a sandbox with a branchspec consisting
solely of one simple text file with non-overlapping changes.

FWIW, I have since updated my scripts to call p4 integ -n on the
results of interchanges, but it slows the script down greatly due to
an overwhelming number of "re-checks", most of which are unnecessary.

I was hoping to be able to use 'integrated' on the target file in
branchMain and cache the results to limit the number of server
requests, but AFAIK it is non-trivial in general to determine the
destination file given the source file and a branchspec. I don't want
to have to implement branchspec mapping manually. Is there a fast,
straightforward way to do this?

Thanks,
Wes


On 10/9/07, Robert Cowham <robert at vaccaperna.co.uk> wrote:
> Don't forget that interchanges is reporting changelists not revisions.
>
> Also that if you integrate part of a changelist then you start getting
> "incorrect" data (or double counted changelists).
>
> So if foo.txt#3 is part of changelist 123 but there are some other files in
> changelist 123, then interchanges will report that as needing to go across,
> even though part of it has already gone.
>
> For belt and braces in this type of reporting you have to treat interchanges
> output with a pinch of salt and back it up with analysis of integ -n output.
> Of course if your development process is such that people never integrate
> partial changelists, your life will be easier...
>
> Does that help?
>
> Robert
>
> > -----Original Message-----
> > From: perforce-user-bounces at perforce.com
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of Wesley Hunt
> > Sent: 09 October 2007 01:06
> > To: perforce-user at perforce.com
> > Subject: [p4] p4 interchanges question
> >
> > p4 interchanges seems to report all revisions after the 1st
> > non-integrated revision as needing to be integrated,
> > regardless of whether those revisions have been integrated.
> > Does anyone know if this is intended or a bug?
> >
> > It only matters when one "cherry-picks" a change for
> > integration. For example:
> >
> > <ASCII ART>
> >
> > BranchRelease: Foo.txt - #1 ----- #2 ----- #3
> >                           ^                 |
> >                  (branch) |                 | (merge)
> >                           |                 v
> > BranchMain   : Foo.txt - #1----------------#2
> >
> > [Let's please ignore the philosophical questions of whether
> > this is a good idea (yes, I've read Practical Perforce,
> > etc... :). That ship has unfortunately sailed]
> >
> >     p4 interchanges -b ReleaseToMain
> >
> > will report change #2 AND #3 need to be integrated. Obviously running
> >
> >     p4 integrate -b ReleaseToMain //...Foo.txt#3,#3
> >
> > will report
> >
> >     all revisions already integrated.
> >
> > So it seems p4 interchanges is not handling cherry-picking...?
> >
> > -Wes
> > _______________________________________________
> > 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
>


More information about the perforce-user mailing list