[p4] finding a branch point

[Jeff Bowles]

> From perforce-user-admin at perforce.com  Sun Jan 11 19:02:15 2004
> From: Noel Yap <Noel.Yap at morganstanley.com>
> To: Stephen Vance <steve at vance.com>
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] finding a branch point
> Date: Sun, 11 Jan 2004 22:04:10 -0500
>
> I think the following should get the branch point:
>
> p4 filelog //depot/foo/bar/1.0/...#1 | grep 'branch from' | awk '{ print $5 }' | xargs p4 changes -m 1 | awk '{ print $2 }' | sort -n -u | tail -1
>
> Does anyone see anything wrong with this?

	Nah, still presents a problem.

	1. First, start using "cut" instead of "awk '{print $2}'". In general,
	   that awk approach went away in 1983 for System V users, a little later
	   for Berkeley folks.
	2. Second, the 'p4 changes -m1' you have is problematic. It'll give you
	   a set of changelists, certainly, but they won't MEAN anything. It'll
	   return to you the single highest-numbered changelist that contributed
	   any contend to your list of files (read from standard input) via a
	   "p4 edit" or "p4 add" (or delete or even 'p4 integrate'), made DIRECTLY
	   to that list of files. (If you'd added "changes -i", then it would
	   be "made directly to that list, or indirectly to things that were eventually
	   propagated to the files you cite.)
	3. The comment about "cut"? Duplicate it, although not the vitriol, for
	   "xargs p4 cmd" (which can and should be replaced with the more portable
	   version, which is "p4 -x - cmd" ('-x -' means 'read from standard input';
	   '-x jojo.txt' means 'read from jojo.txt, one filename at a time.]

	The real hassle is that it's not clear what your object is. (Okay, and that
	Perforce didn't scribble, into a label, what the starting revisions for the
	branch were when you ran "p4 integ place1/... place2/... ; p4 submit". If you
	had known, you could've labeled place1/... first. That, however, isn't your
	fault - we ALL find ourselves in this boat at least once.)

	If you want to know, for a given "p4 integ place1/... place2/... ; p4 submit"
	where you retrieved the files from place1/... (which revisions), then something
	like the "p4 filelog place2/...#1 | grep 'branch from' | parse-that-sucker.pl"
	will give you a useful file list.

	However, and this is the "still a problem" part, that's for the starting
	point. (And we're assuming that there were no branches made after that moment
	that created the branch - say, branching a makefile from place1/... a day later
	because you decided you wanted it into place2/... after all.)

	You still have the problem that place1/... at 123023 might've been the starting
	point to create place2/..., but that since then you've integrated a few bug
	fixes from place1/... (changelist 123100, 123201, and 123205, but nothing
	inbetween). Given that, there are three scenarios to contend with:
		a. Nothing else changed in place1/... since changelist 123023 except
		   in those three changelists. To paraphrase, place1/... at 123023
		   and place1/... at 123205, IN THIS SPECIFIC EXAMPLE, could be the
		   exact some contents. No big deal, celebrate and find the scotch.
		b. For those additional integrations from place1/... to place2/...,
		   the files you pulled down "later" were really unmodified (in place1)
		   except for the changelists you pulled down explicitly. Making a label
		   that reflects place1/... at 123023 and then including the files from
		   place1/... modified in 123100, 123201, and 123205 at the 123205
		   revision - and leaving the rest of the label alone - is a workable
		   strategy. Also a very lucky one.
	These two options are practically a fantasy, because they're so unrealistic
	and so tidy. The more likely scenario is:
		c. You've made an initial branch, and pulled down a handful of bug
		   fixes since then. "place1/x.c" has continued development since
		   place2/x.c was made, and you've integrated three revisions of
		   place1/x.c into place2/x.c using selective integrations, but left
		   another 14 revisions of 2.0 work in place1/x.c for later. No
		   label or specification of place1/x.c will describe this, although
		   the integration history of place1/x.c and place2/x.c will [at least]
		   tell you what happened.
	
	If you're trying to create a place2.1/... for a point-release, you can start
	with the place2/... content (using the same starting point as place2/... started,
	with a branch from a specific set of files in place1/... that you CAN reconstruct.)
	Going from there, however, is something you'll have to do slowly and with
	a script - not with a single place1/... at something to integrate to place2.1/...

	I realize this is dense; I hope it's useful.

	-Jeff Bowles