[p4] graphical representation of branches?

[Jay Glanville]

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
>