[p4] graphical representation of branches?
Jay Glanville
Jay.Glanville at naturalconvergence.com
Tue Sep 26 08:13:03 PDT 2006
Ah, David, I've realized my mistake. I thought that the "p4 -ztag
integrated" command required a file path. At least, that's what the
command reference says
(http://perforce.com/perforce/doc.061/manuals/cmdref/integrated.html#104
0665). But, apparently that isn't required. (This is why I thought I
needed a "Methuselah" file.)
Thanks for the info David.
---
Jay Dickon Glanville
> -----Original Message-----
> From: Weintraub, David [mailto:david.weintraub at bofasecurities.com]
> Sent: September 26, 2006 10:43 AM
> To: Jay Glanville; Perforce Users Mailing List
> Subject: RE: [p4] graphical representation of branches?
>
>
> > 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
> >
>
More information about the perforce-user
mailing list