Jump to content

Stream depots and multiple mainlines

stream mainline multiple

  • Please log in to reply
1 reply to this topic

#1 jaime_rios



  • Members
  • Pip
  • 7 posts

Posted 29 August 2013 - 03:01 PM

Recently, our organization began using streams for new software development, but we are facing some questions about the structure of our Perforce server which may differ greatly from how we previously had our server set up.

In our current Perforce depot structure, we have the following:

When projects were feature-set-frozen and ready to be released, they were integrated into the //depot/Products folder.

Obviously, all of our projects are housed in //depot/Projects and commonly used code across all projects were held in //depot/Shared.

This structure was not perfect, but for the time being, everyone in our organization understood this structure and how to work with it.

Now, we have newer projects, which we opted to use streams:

Obviously, I obfuscated the names of the projects for security purposes, but the intent should be clear.

Now, I am working on another library project, and my admin and I created a //Libraries stream depot instead of creating a new stream deport for the project, with the hopes of containing all of the future library development in the same stream depot to potentially reduce the clutter in the depot view that might happen with creating a stream depot for every future library project.

So, I created a mainline named //Libraries/libraryprojectb_main, but, in re-reading the Perforce guides, I read how there should only be 1 mainline in a stream depot.

As a test, I created 2 mainline depots in the //Libraries stream depot and saw that Perforce didn't try to stop me; in the stream depot view, I saw the 2 mainlines side by side.

So, and here is question 1, although it is possible to have multiple mainlines in a stream depot, is this something that is recommended or should be avoided?

Question 2, if it not recommended to have multiple mainlines in a stream depot, are we expected to have really long lists of projects in our depot view?

I recognize that these questions may be similar to  http://forums.perfor...r-all-projects/ but I wanted to make sure what we may be doing is correct.

#2 P4Matt


    Advanced Member

  • Members
  • PipPipPip
  • 1383 posts

Posted 03 September 2013 - 06:57 AM

The answer to 1) is you can certainly do it; it just makes it harder for us to draw pretty pictures. =D I'd say in general we recommend one project per stream system because then you can be guaranteed that all of the streams have related code. (what happens if you reparent a dev stream between mainlines?) If the multi-mainline approach works for you go for it. The worst that happens is you have to migrate some of that code out later. All of our tools are supposed to be setup to handle that case.

The real answer to 1) is we need to provide the ability to have more depth to stream names; using multiple mainlines is a workaround for the lack of name spacing that comes with a two tier system. Till we get that done, multimainline seems like a legit way to go.

As for 2), if you go with a stream system per project/library then you do indeed end up with a very long list of depots. I think of it as a bit more like the GitHub workflow of having tons of small projects. There are advantages with each setup.

Strangely enough I've been wrestling with this very same problem with my work on the various sites I maintain here at Perforce. It seems like overkill to create a separate stream depot for the forum software, but at the same time I don't want to conflate that code with the Public Depot/Swarm code. I think the fact it impacts the depot view as you pointed out is what pushes me away from making a lot of stream depots, but at the same time, there's a reason P4V has an option to filter the depot view by the current workspace!

At the end of the day there is no right answer for this. I'd say do what works, but tend towards separate depots when possible.

Also tagged with one or more of these keywords: stream, mainline, multiple

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users