Jump to content


Many Streams... is that right?

stream

  • Please log in to reply
3 replies to this topic

#1 Hyunjik Bae

Hyunjik Bae

    Member

  • Members
  • PipPip
  • 15 posts

Posted 24 May 2015 - 02:07 AM

We are using Streams like this:

master: official release
dev0xx: adding or updating features

While we are going on, the number of dev0xx is sometimes increasing, though we are reusing freed (i.e. become unused after copied to the master). the number became up to 27!

Posted Image

I sometimes think using Streams like this is weird, but I cannot find a better way.

Am I on the right track? If not, what is the better way?

#2 P4Sam

P4Sam

    Advanced Member

  • Members
  • PipPipPip
  • 484 posts
  • LocationSan Francisco, CA

Posted 24 May 2015 - 06:52 PM

What you have is an excellent  use case for task streams.  The general idea behind task streams is that you create a new one for each task, and then either delete or unload it when the task is done.  (I recommend unloading rather than deleting, because then it's easy to bring it back if needed.)  Once the task stream is deleted/unloaded you don't see it in the stream graph any more, and the branched files you didn't change aren't in the depot, but the changes you made are still preserved.  (If you're using task streams, you don't reuse "freed" names, you just keep making new ones.)

#3 keynode

keynode

    Newbie

  • Members
  • Pip
  • 7 posts

Posted 11 June 2015 - 06:26 PM

View PostP4Sam, on 24 May 2015 - 06:52 PM, said:

What you have is an excellent  use case for task streams.  The general idea behind task streams is that you create a new one for each task, and then either delete or unload it when the task is done.  (I recommend unloading rather than deleting, because then it's easy to bring it back if needed.)  Once the task stream is deleted/unloaded you don't see it in the stream graph any more, and the branched files you didn't change aren't in the depot, but the changes you made are still preserved.  (If you're using task streams, you don't reuse "freed" names, you just keep making new ones.)

But unloaded/deleted streams still appear in the depot tree view,
This view very fast becomes unmanagable as so many new task streams appear in it. (and never dissappear)
And this view is currently neccessary because stream graph surprisingly does not provide a way to see change history or submits in a stream without falling back to select this stream in depot tree view
Is it meant to be this way?

#4 Krzysztof Nosek

Krzysztof Nosek

    Member

  • Members
  • PipPip
  • 21 posts

Posted 24 August 2015 - 08:26 PM

I wholeheartedly second other users with the raised points. The tools for browsing streams (specs & history) still require love.

Every time I drag my workspace icon to another stream, and notice it's past the border of the current view and the window doesn't autoscroll... something dies in me. :)
We can't hide streams of given type (e.g. task or virtual) or search for them by name/owner (while we can do this for branch mappings).

In the particular case of jumping to stream files' history:
There's a great hidden feature of dragging & dropping a depot/stream from the Depot View to Stream View's "Depot:" combo. This quickly switches the Stream View between depots. (MUCH faster than actually using the combo box!)
Why can't we drag the other way round, i.e. drag a stream from the Stream View directly to the Address Bar? Or, par chance, to the "Files match any of the following file paths:" combo box in Submitted Changelists view?





Also tagged with one or more of these keywords: stream

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users