Specifying a Stream for Perforce

[Nick_Riggs]

Hi,

I upgraded Flare and Perforce today to their latest respective versions.

I have a Flare project in Perforce, so I am using the File > Source Control > Import Project command to establish a link to that project. I can specify the server and then select my User name from a dropdown list. The Stream field is greyed out.

If I click Next, a message comes up saying "Stream cannot be empty". But if I click Browse, I get:

System.NullReferenceException occurred at ....
Object reference not set to an instance of an object.

So it seems I can't continue, unless I should be doing something else...?

[Msquared]

This could possibly be a bug. As you know Perforce integration with Flare is very new still. I'm still on Flare 9, and haven't tried it yet in Flare 10 although I hope to do so soon.

However, in previous versions of Flare, I found that importing a project from Perforce just didn't work, and the symptoms were similar to yours. You needed to select something in order to continue, but you weren't able to.

So I don't import projects from Perforce using Flare. I just get them directly into my workspace using the Perforce client, P4V, then open the project file in Flare.

[Thomas Bro]

The Stream integration is per design. Alas, since it leaves a whole bunch of people unable to use the Flare 10 integration of Perforce.

If you use Streams, the next hurdle, which is actually worse, I think, is that once an old Flare project (which is in Perforce already) is either bound to Perforce, or imported from Perforce, the entire history of this is lost.

Keep smiling
Thomas

[Msquared]

Hi Thomas,

I've not looked at Perforce in Flare 10 yet (too many other more important things to do first), but are you saying that Perforce integration in Flare doesn't support repositories that use streams (we use streams)?

Or are you saying that if your Perforce implementation uses streams, then somehow, once you bind a Flare project to Perforce, all the existing Perforce history for those files is somehow lost for ever? And by "lost" you mean that it can't be viewed directly in the Perforce client either? I'm puzzling how Flare can destroy what is already in the repository.

The only problem I have with Perforce and streams in Flare 9 is exactly the same as I had when we used to use branches, and it's not really a Perforce issue, but more a Flare issue in general. The issue is that Flare projects aren't relocatable - everyone who builds them will need to have the same folder structure as you, since external references are stored as absolute filenames. So I always map my documentation root to P:. Then, external; references are always relative to P:. If you are working on projects in multiple streams it can get a bit messy, since you have to remember to do the mapping each time, and perhaps more importantly, remember which stream you have mapped to P: and not try to open a project from one stream in Flare if you currently have P: mapped to another stream. I just make sure I close all instances of Flare and of the P4V client before I switch the mapping, then re-open the required Flare projects and Perforce workspaces after the switch. I never switch streams in Perforce by dragging the view icon! That's guaranteed to get confusing.

[shannong]

Hi Thomas,

I've not looked at Perforce in Flare 10 yet (too many other more important things to do first), but are you saying that Perforce integration in Flare doesn't support repositories that use streams (we use streams)?

Or are you saying that if your Perforce implementation uses streams, then somehow, once you bind a Flare project to Perforce, all the existing Perforce history for those files is somehow lost for ever? And by "lost" you mean that it can't be viewed directly in the Perforce client either? I'm puzzling how Flare can destroy what is already in the repository.

The only problem I have with Perforce and streams in Flare 9 is exactly the same as I had when we used to use branches, and it's not really a Perforce issue, but more a Flare issue in general. The issue is that Flare projects aren't relocatable - everyone who builds them will need to have the same folder structure as you, since external references are stored as absolute filenames. So I always map my documentation root to P:. Then, external; references are always relative to P:. If you are working on projects in multiple streams it can get a bit messy, since you have to remember to do the mapping each time, and perhaps more importantly, remember which stream you have mapped to P: and not try to open a project from one stream in Flare if you currently have P: mapped to another stream. I just make sure I close all instances of Flare and of the P4V client before I switch the mapping, then re-open the required Flare projects and Perforce workspaces after the switch. I never switch streams in Perforce by dragging the view icon! That's guaranteed to get confusing.

I'm late to the party on this thread, but since it's still on the first page I'll add my two cents to help the next poor fool who struggles with Perforce integration. ^.^

First, more detail behind what I'm about to say can be found here: http://forums.madcapsoftware.com/viewto ... 96#p103945


1. If you move from non-integrated Flare projects (in Perforce) to integrated projects, you will lose all Perforce history if your projects currently live in a "classic" depot. If your projects already exist in a stream depot, then you won't lose anything. The issue here is that Flare's integrated source control features for Perforce work only with stream depots.

2. What you say about every author needing to use the same absolute path to their flare project for building output targets is true. But you don't need to jump through continual drive-mapping hoops to accomplish this, provided you do NOT bind your projects to Perforce. If you work in an non-integrated manner, it's very easy to ensure that every author has exactly the same absolute path for builds by enforcing policy about workspace names and workspace root paths. This is effectively impossible in integrated Flare projects, because Flare insists on creating an entirely new workspace for you when you first open a Perforce-bound project file. This results in every author having a long and redundant (but unique) workspace name for their local version of the project. However, if you work only with unbound projects, then it's a simple matter to use identical naming conventions when creating their own workspace for a stream. For example, our conventions are to: A) specify a Workspace name that is a simple contatenation of the depot name and the stream name (e.g., "doc_intFall14", and then to change all but the last segment of the Workspace root to be "c:\flareP4". The resulting absolute folder path on every author's local computer ends up being: "c:\flareP4\doc_intFall14"