Flare 11 with Perforce - Performance Question

[scooter262]

We use Flare 11, and we currently have Perforce. (Side note: it's possible we will be moving to Git/GitHub.)

We have a fairly large project -- 1250 or topics, 2000+ images. To date, we've not bound our projects to SC in Flare. However, we just started using Flare 11 (most of us were on 9), and we're also moving this large project from another tool into Flare, so we thought it might make sense to bind to SC now.

As far as I can tell, the main pro (and it is a big one, especially with a large project) is that moving/renaming files would be much simpler if project is Bound. It is a real hassle, as most of you probably know, if the project is separate from SC.

However, I'm worried about the main con: performance. We have a geographically distributed team, plus a fairly large, complex network.

Does anyone have experience and/or suggestions? Anyone using Flare 11 and Perforce and binding their projects and not having too much degradation in performance?

[Nita Beck]

As far as I can tell, the main pro (and it is a big one, especially with a large project) is that moving/renaming files would be much simpler if project is Bound. It is a real hassle, as most of you probably know, if the project is separate from SC.

(Caveat: I've never used Perforce. I've used Subversion and Git for source control of my Flare projects.)

I don't think source control has anything to do with how easy or not it is to rename and move files in Flare. You will still absolutely want to do renames and moves from within Flare so that Flare can manage the internal dependencies (the links) between files. In my experience, when using Subversion, the Flare renames/moves were actually somewhat harder than for an unbound project. But I digress...

To me, the advantages of putting Flare projects in source control are these (in random order):
-- Makes it easy for a team of authors to co-author Flare projects.
-- Can roll back to earlier versions of files, if necessary.
-- Can create branches in order to work in a way that doesn't disturb others working on the main line of development.
-- Provides an easy backup mechanism for Flare projects.
-- Can view the history of a project, of individual files. Hopefully, the authors add comments when they commit changes, which is helpful when going back to see what was done when.

And I'm sure there are more advantages, but these are the ones that come readily to mind...

[scooter262]

We are putting the project in source control. That's not the question.

However, just because the files are in source control, that is not the same as using Flare's Bind to Source Control option.

If not bound, then authors check out files (Perforce), work on them and save them (Flare) and then check them in (Perforce).

If bound, then authors don't ever need to interface directly with Perforce -- they work on files and save them all in Flare. Behind the scenes, Flare is doing the Perforce checkins and checkouts.

I'm wondering about that aspect regarding performance. That is, when working in Flare, how much slow-down will there be when working on and saving files, since all the Perforce stuff is happening at the same time in the background.

[sboltz]

I'm in the process of trying to bind Flare projects to Perforce. Playing in a sandbox right now and have tried both Streams and Depots. So far depots are working better which is good as we aren't as familiar with steams.

The problem is in the performance. Does anyone use Flare in this environment where projects are bound to Perforce? Do you have projects that are imported into other projects as well?

Right now just on an empty test project with only a single topic, it has a delay of 30 seconds to a minute before my typing appears. And if I type a lot it won't capture it all. This is unacceptable so I'm trying to figure out why. Otherwise I'll have to revert to having our team have to manually check in and out files in Perforce which isn't ideal with a distributed team.

I would appreciate any feedback on this as we have to get out of TFS as quickly as possible.

Thanks!

[keuler]

Hi Suzette. I'm wondering if you've received any help with Perforce integration outside of this thread. We are in a similar situation. Some sandbox testing of binding a project to Perforce had some unacceptable performance issues, not to mention odd behavior that locked up my computer several times.

Please let me know about any progress you might have made.

Thanks.

Kurt

[sboltz]

I was unable to get it working satisfactorily. How about you? Maybe down the road we might use a different source control since we can't bind with Perforce. It is a little frustrating because we often move files around and rename them and Perforce doesn't recognize this when you check files in and out manually. This means we have to manually delete them from the project and add the renamed ones as new files. Very inconvenient. We had better integration with TFS but unfortanately we're not continuing to use that product.