[p4] graphical representation of branches?

[Weintraub, David]

> David, if I understand the "p4 -ztag integrated" command correctly,
> it's applied to individual files, correct?  Therefore, I need to find
> a file that exists in all branches in order to use it.

That might work, if you can find such a file. Since that cannot be
guaranteed, you're better off doing what I said: Take the fromFile and
toFile, and remove the common parts. For example:

... toFile //depot/Efp/DataArch/DATA-ARCH-1.0.77.0/CustomDictionary.xml
... fromFile //depot/Efp/DataArch/MAIN/CustomDictionary.xml
... startToRev #none
... endToRev #1
... startFromRev #none
... endFromRev #1
... how branch from
... change 11262

I compare the "toFile" and "fromFile", remove the matching ends and
beginning. This gives me:

MAIN -> branched to -> DATA-ARCH-1.0.77.0

Now, this particular integration might have involved a few hundred
files, but if I throw away duplicates, I'd be left with this single
record. In Perl, you could do something like this:

    $branch{"$fromBranch}->{"$toBranch"} = 1;

for each integration record you've parsed. That will take care of the
duplicate problem. The advantage is that I don't depend upon some
possibly non-existent Methuselah file that is involved in all branchings
and all versions of my depot.

My only question is whether you might end up with two records:

MAIN -> branched to -> DATA-ARCH-1.0.77.0

And

DATA-ARCH-1.0.77.0 -> branched to -> MAIN

The second record would occur when you integrate changes from
DATA-ARCH-1.0.77.0 back to MAIN.

In this case, you may need to save the changelist number, and throw out
the pair that has a latter change list number.

In Perl, the code would look something like this:

    if ($branch{"$fromBranch"}->{"$toBranch"}) {
        if ($currentChangeNum < $branch{"$fromBranch"}->{"toBranch"}) {
            $branch{"$fromBranch}->{"$toBranch"} = $currentChangeNum;
        }
    } else {   #No Changelist
        $branch{"$fromBranch}->{"$toBranch"} = $currentChangeNum;
    }

That way, you store the earliest changelist number associated with each
branch. Then, after you've finished parsing the branches, you'll need to
do this:

    foreach $fromBranch (keys (%branch)) {
        foreach $toBranch (keys (%{${branch{$fromBranch}}}) {
            if (exists ${$branch{$toBranch}}{$fromBranch}) {
                if (exists $branch{$fromBranch}->{$toBranch} <
$branch{$toBranch}->{$fromBranch}) {
                    delete ${$branch{$toBranch}}{$toBranch};
                } else {
                    delete ${$branch{$toBranch}}{$fromBranch};
                }
            }
        }
    }

What this is doing is storing the lowest changelist number involved in
each pairing of <fromBranch>-><toBranch> on the assumption that the
lowest changelist number involved is the first instance of this pairing.

Then after I create my pairings, I take each instance of
<fromBranch>-><toBranch> and I ask the following question:

* Is there also a <toBranch>-><fromBranch> pair?
* If so, which pairing has the lowest changelist number?

I delete either the pair <fromBranch>-><toBranch> or the pair
<toBranch>-><fromBranch> by deleting the pair with the highest
changelist number and keeping the pair with the lowest changelist
number. I do this on the assumption that the lowest changelist number
represents the original branch while the higher changelist number is
simply a delivery of new branch code back to the original branch.

I hope I've got the Perl syntax correct. This is one of those cases
where I agree with the Python people that Perl's syntax is more
confusing than Python's. However, you should have the general idea.


-----Original Message-----
From: Jay Glanville [mailto:Jay.Glanville at naturalconvergence.com] 
Sent: Tuesday, September 26, 2006 9:59 AM
To: Weintraub, David; Perforce Users Mailing List
Subject: RE: [p4] graphical representation of branches?

David and Paul,

Thanks for the responses.  Both of you pointed out that branch
specifications are just templates and not branch definitions.  Valid
point.

Would it make a difference if our product branching policy was, "create
branch spec, apply spec right away"?  In other words, we've been pretty
consistent in the way that we've been creating branches: create the
specification and then use it to integrate that day.  With this
additional information, can I still rely on branch specs, or does (1)
below still apply?


David, if I understand the "p4 -ztag integrated" command correctly, it's
applied to individual files, correct?  Therefore, I need to find a file
that exists in all branches in order to use it.


Thanks

---
Jay Dickon Glanville


> -----Original Message-----
> From: Weintraub, David [mailto:david.weintraub at bofasecurities.com]
> Sent: September 26, 2006 9:28 AM
> To: Jay Glanville; Perforce Users Mailing List
> Subject: RE: [p4] graphical representation of branches?
> 
> 
> Branch specs don't do any good because you cannot trust that 1). A 
> branch was actually created using a branch specification. 2). That a 
> branch specification was even used to create the branch specified, and

> especially 3). That the branch specification even matches the way 
> files were actually branched.
> 
> The other problem with Perforce is that Perforce doesn't really 
> understand the concept of directories. Sure, files are on directories,

> but all Perforce actions takes place on files and not directories. In 
> theory, //depot/MAIN/foo.c could have been branched to 
> //depot/REL1/foo.c, but //depot/MAIN/bar.c was branched to 
> //depot/REL2/bar.c -- or even //depot/REL2/foo.c. You can't tell 
> except by looking at each and every file and on each and every branch.
> 
> If you followed Laura Wingerd's recommendation that branch names are 
> all uppercase, you could go through your Perforce depot looking for 
> all directories that are completely uppercase. Some users do not 
> flatten their branching structure, so they're depot looks something 
> like this:
> 
> //depot/Acme/MAIN/...
> //depot/Acme/MAIN/REL1/...
> //depot/Acme/MAIN/REL1/REL1.1/...
> //depot/Acme/MAIN/REL2/...
> 
> Instead of the more standard:
> 
> //depot/Acme/MAIN/...
> //depot/Acme/REL1/...
> //depot/Acme/REL1.1/...
> //depot/Acme/REL2/...
> 
> That way, the branch directory names reflect the branching structure.
> This makes something you want to do a lot easier. Of course, it also 
> means that the Perforce protection table gets a bit more complex (How 
> do you give a user permission to work the directories and files off of

> branch //depot/Acme/MAIN/..., but not on files and directories that 
> are on a branch that branched off of //depot/Acme/MAIN/...?).
> And, it makes
> assumptions of where to find branch names much harder. (In the second 
> layout, branch names are all on the third directory on the depot tree.
> In the first layout, they could be anywhere on the depot tree).
> 
> The only real way to do this is to run the "p4 -ztag integrated" 
> command and parse away. Each entry gives you a "toFile" and a 
> "fromFile".
> Compare these, and remove the end parts of the two that match. This 
> will give you the branching directory names. Store these in the form 
> of "fromDirectory -> toDirectory" pairs and throw away duplicate 
> pairings.
> 
> Once you've parsed all of the file entries, you're left with a few 
> dozen branch pairings. Now it's an easy step from taking these 
> individual branching pairs to constructing the actual branching tree 
> structure they represent. (That is, if you weren't like me and 
> actually paid attention in your data structures class.) A simple task 
> really. No more difficult than taking individual snippets of DNA and 
> reconstructing an entire genome.
> 
> Sorry, Unfortunately, I really cannot think of an easier way of doing 
> this. Like all version control systems, Perforce really doesn't 
> understand what branches really mean. All version control systems 
> create branches off of individual files or directories.
> 
> Branches don't branch off of files! Branches branch off of other 
> branches! Maybe one day, some version control system will understand 
> this concept.
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jay Glanville
> Sent: Tuesday, September 26, 2006 8:05 AM
> To: Perforce Users Mailing List
> Subject: [p4] graphical representation of branches?
> 
> Hello all you fellow P4'ers
> 
> I want to create a graphical representation of all the branches that a

> product of ours has gone through.  I know that P4 doesn't provide this

> functionality natively, so I was wondering if anyone in the
> P4 community
> has developed such a tool.  Before somebody says, "don't forget the 
> 'Revision Graph ...' functionality in P4V", yes, that's great, but 
> it's just for a specific file, not for branches.
> 
> I was thinking that the branch specifications would be a good data 
> source for this information (from, to, date, reason, name, etc).
> 
> So, has anyone already developed such a tool?  If not and I need to 
> write such a tool, is branch specifications the appropriate data 
> source?
> 
> Thanks
> 
> JDG
> 
> ---
> Jay Dickon Glanville
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>