• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Indexing
    • None
    • 149
    • 1
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      p4 2011.1 introduced a new feature called "streams" which is similar, but not the exactly the same as a branch. while fisheye will index commits on a "streams" depot, the streams will not be recognised as separate branches.

      we should be checking for streams as well as branch specs when indexing commits.

      a current workaround is to create branch specs to match the streams.

      ----------------

      here you can see the commits that were actually made:

      And the fact that all commits appear on the "head" branch:

      Using the workaround, i created 2 branch specs:
      MAIN (//depot/... //depot/MAIN/...)
      DEV (//depot/MAIN/... //depot/DEV/...)

      The commits are now represented in the following way (note the DEV branch spec):

      And they appear like the following when browsing in FishEye:

        1. FE3886_1.png
          FE3886_1.png
          15 kB
        2. FE3886_2.png
          FE3886_2.png
          14 kB
        3. FE3886_3.png
          FE3886_3.png
          15 kB
        4. FE3886_4.png
          FE3886_4.png
          9 kB
        5. FE3886_5.png
          FE3886_5.png
          9 kB

            [FE-3886] Support for Streams in p4

            Atlassian Update – 19 May 2020

            Hi everyone,

            thank you very much for reporting this suggestion and your involvement in the conversations around it. This suggestion is in the 'Reviewing' state which means it awaits assessment by our team.

            As Fisheye and Crucible have entered basic maintenance mode, our team currently focuses more on bug-fixes and platform updates rather than on feature development. We may still deliver some small improvements if they fit into the maintenance theme. However, suggestions which have been assessed already and are in the Under consideration state have higher priority.

            It means it may take time until we review this suggestion and decide whether to put it on the roadmap or reject it. You can expect an update from us in couple of months. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.

            Kind regards
            Marek Parfianowicz
            Development Team Lead
            Fisheye/Crucible Team

            Marek Parfianowicz added a comment - Atlassian Update – 19 May 2020 Hi everyone, thank you very much for reporting this suggestion and your involvement in the conversations around it. This suggestion is in the 'Reviewing' state which means it awaits assessment by our team. As Fisheye and Crucible have entered basic maintenance mode , our team currently focuses more on bug-fixes and platform updates rather than on feature development. We may still deliver some small improvements if they fit into the maintenance theme. However, suggestions which have been assessed already and are in the Under consideration state have higher priority. It means it may take time until we review this suggestion and decide whether to put it on the roadmap or reject it. You can expect an update from us in couple of months. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments. Kind regards Marek Parfianowicz Development Team Lead Fisheye/Crucible Team

            Bumping this again - We currently have to maintain several hacks/workarounds to use both FishEye and Bamboo as a result of this, which limits the functionality of both products.

            At some point in the not distant future this will no longer be a viable option and we will need to consider other solutions.

            Thanks!

            Lenore Gilbert added a comment - Bumping this again - We currently have to maintain several hacks/workarounds to use both FishEye and Bamboo as a result of this, which limits the functionality of both products. At some point in the not distant future this will no longer be a viable option and we will need to consider other solutions. Thanks!

            We have more and more of our users complaining and providing workaround often is not a feasible approach.

            Kind request to provide the support to P4 streams feature in the very near future - perhaps the next release.

            Regards,
            Rahul Savaikar

            Rahul Savaikar added a comment - We have more and more of our users complaining and providing workaround often is not a feasible approach. Kind request to provide the support to P4 streams feature in the very near future - perhaps the next release. Regards, Rahul Savaikar

            Please provide support to P4 streams feature.  Workaround is difficult to maintain in a dynamic production env.

            Joseph Chung Yin added a comment - Please provide support to P4 streams feature.  Workaround is difficult to maintain in a dynamic production env.

            Edil Cadenas added a comment - - edited

            Is this being looked into at all from Atlassian? Any update on fixes, not workarounds?

            @Jonathan: we have the same problem (re: task streams). We also noted that doing a full re-index somehow "fixes" the problem, but as you noted, this isn't very ideal to do on a production server.

            Edil Cadenas added a comment - - edited Is this being looked into at all from Atlassian? Any update on fixes, not workarounds? @Jonathan: we have the same problem (re: task streams). We also noted that doing a full re-index somehow "fixes" the problem, but as you noted, this isn't very ideal to do on a production server.

            We are currently using Task Streams in P4 and have noticed a significant problem with Fisheye scanning changesets. The very first changeset within a task stream (the one that populated/branched files) is a special changeset that changes it's list of files as commits are done within the task stream. This means that quite often Fisheye will have ignored this first changeset because during an incremental index, the changeset had no files. The impact is that without this first changeset, the files to undergo a Crucible review often have no base revision and therefore no diffs can be seen.

            The only way around this problem that we know of is to perform a full re-index, which is obviously far from ideal. I wonder if anyone else using P4 Task Streams has observed this issue. We are interested in any 'decent' workarounds until P4 Streams support is implemented in Fisheye.

            If P4 Streams support ever gets worked on by Atlassian, please consider P4 Task Streams and their unique behaviour to ensure that the issue I described above is resolved.

            Jonathan Magtalas added a comment - We are currently using Task Streams in P4 and have noticed a significant problem with Fisheye scanning changesets. The very first changeset within a task stream (the one that populated/branched files) is a special changeset that changes it's list of files as commits are done within the task stream. This means that quite often Fisheye will have ignored this first changeset because during an incremental index, the changeset had no files. The impact is that without this first changeset, the files to undergo a Crucible review often have no base revision and therefore no diffs can be seen. The only way around this problem that we know of is to perform a full re-index, which is obviously far from ideal. I wonder if anyone else using P4 Task Streams has observed this issue. We are interested in any 'decent' workarounds until P4 Streams support is implemented in Fisheye. If P4 Streams support ever gets worked on by Atlassian, please consider P4 Task Streams and their unique behaviour to ensure that the issue I described above is resolved.

            oh, one final comment for today! Note virtual streams also don't show up in the list of 'branches'. release, mainline, development and task branches all showed up if you set up a repository with a path of //<stream depot>/...

            I will also add a warning. If you have two or more repositories indexing the same perforce depot (probably true for other VCT's), crucible will store the same information two or more times. So if you have a crucible repo with path //river/..., a different crucible repo with path //river/main/..., and a different repo with path //river/devA/..., then the streams main and devA are in twice (once from //river/... and once from //river/<stream>/...). You could fill up your FISHEYE_INST location if you have limited disk space. deleting a stream (or unloading a task stream/set of labels) will free up some space once crucible re-indexes after a minute or so).

            Marc Towersap added a comment - oh, one final comment for today! Note virtual streams also don't show up in the list of 'branches'. release, mainline, development and task branches all showed up if you set up a repository with a path of //<stream depot>/... I will also add a warning. If you have two or more repositories indexing the same perforce depot (probably true for other VCT's), crucible will store the same information two or more times. So if you have a crucible repo with path //river/..., a different crucible repo with path //river/main/..., and a different repo with path //river/devA/..., then the streams main and devA are in twice (once from //river/... and once from //river/<stream>/...). You could fill up your FISHEYE_INST location if you have limited disk space. deleting a stream (or unloading a task stream/set of labels) will free up some space once crucible re-indexes after a minute or so).

            Note though, while most things in crucible seem to support streams after having setting up one perforce branch, it flat out doesn't work when, on adding content, if you pick 'Choose branches'. No stream works as of crucible 3.7.

            Pretty much everything else seems to work

            Using pre-commits via crucible.py, mostly works. I had some issues with particular types of files that crucible.py pukes over when trying to generate diff's, and it seemed to not work on binary files (I think I tried a wmv) that are 'marked for add (p4v)' or added via p4 add. i've got to play more to verify this though (it might have been just over some temp file that gvim created that I added just for testing). regular text files worked perfectly fine in crucible.py.

            Marc Towersap added a comment - Note though, while most things in crucible seem to support streams after having setting up one perforce branch, it flat out doesn't work when, on adding content, if you pick 'Choose branches'. No stream works as of crucible 3.7. Pretty much everything else seems to work Using pre-commits via crucible.py, mostly works. I had some issues with particular types of files that crucible.py pukes over when trying to generate diff's, and it seemed to not work on binary files (I think I tried a wmv) that are 'marked for add (p4v)' or added via p4 add. i've got to play more to verify this though (it might have been just over some temp file that gvim created that I added just for testing). regular text files worked perfectly fine in crucible.py.

            Marc Towersap added a comment - - edited

            hmm... I got crucible 3.7 to seem to work with p4 streams by setting up a single branch spec.
            I did p4 streams, picked a non-mainline stream, then did p4 branch -S <devstream> -o <depot>_<devstream>2<parentstream> | p4 branch -i

            For example, I have a depot named blah, and a mainline stream 'main' and a dev stream 'dev' who's parent is main. So I did p4 branch -S //blah/dev -o blah_dev2main | p4 branch -i

            Then when I set up my crucible repository to index the blah stream (path //blah/... ), it just worked even though there were other streams (dev2, rel1.1, rel1.2, etc.)

            The only streams that were missing where streams that were created, but not populated (aka not branched), and they should be skipped (they are empty streams)

            I created a new stream depot called asdf, created a mainline stream, populated with with stuff, then set up a crucible repository for it (path //asdf/...) and it worked too, even though there are no branchspecs for that depot at all.

            uh, do I trust it? I can see it refreshing every minute, a change/submit I just did showed up in crucible...

            Marc Towersap added a comment - - edited hmm... I got crucible 3.7 to seem to work with p4 streams by setting up a single branch spec. I did p4 streams, picked a non-mainline stream, then did p4 branch -S <devstream> -o <depot>_<devstream>2<parentstream> | p4 branch -i For example, I have a depot named blah, and a mainline stream 'main' and a dev stream 'dev' who's parent is main. So I did p4 branch -S //blah/dev -o blah_dev2main | p4 branch -i Then when I set up my crucible repository to index the blah stream (path //blah/... ), it just worked even though there were other streams (dev2, rel1.1, rel1.2, etc.) The only streams that were missing where streams that were created, but not populated (aka not branched), and they should be skipped (they are empty streams) I created a new stream depot called asdf, created a mainline stream, populated with with stuff, then set up a crucible repository for it (path //asdf/...) and it worked too, even though there are no branchspecs for that depot at all. uh, do I trust it? I can see it refreshing every minute, a change/submit I just did showed up in crucible...

            Although FisheEye is a great tool we had to decide against using it because of the lack of streams support.

            Georg Holzer added a comment - Although FisheEye is a great tool we had to decide against using it because of the lack of streams support.

              Unassigned Unassigned
              gcrain Geoff Crain (Inactive)
              Votes:
              68 Vote for this issue
              Watchers:
              46 Start watching this issue

                Created:
                Updated: