Old, tabbed interface bug, fixed before release??

[mgillespie]

From the old Wordpress board..

Mark Gillespie says:

March 9th, 2007 at 4:12 am
Still exhibiting the bug in build 425, opening files when using the tabbed Interface from a source control problem with Cirrus already running.

Not sure if you had planned to address this in 425, but if you have, it’s still borked

Scooter says:

March 9th, 2007 at 9:54 am
Mark, the solution is to add the new /solo switch to the command line called from CM. Have you tried that?

Thanks,
Tim

Mark Gillespie says:

March 14th, 2007 at 7:38 am
I have tried the Solo switch, and it opens new sessions of Cirrus in new windows, not new tabs.. Kinda defeats the point of having tabs…

Michael Bulgrien says:

March 14th, 2007 at 9:44 am
The whole point is that sessions launched by source control should be isolated instances to preserve their integrity. I don’t know of any other merge product that opens source control sessions in a child window under an already open merge product. The tabbed interface is to support all other user initiated sessions.

Scooter says:

March 14th, 2007 at 10:07 am
Michael is correct, the whole point of /solo is to open a completely independent instance of Cirrus. It was the easiest way for us to deal with CM wanting to know when Cirrus is done with the temp files so CM can delete them.

We have sketched out a more sophisticated design where a new instance of Cirrus runs hidden, passes the filenames onto an existing instance of Cirrus, waits for a message saying that comparison has been closed, and then exits.

So, it’s possible we could support the behavior that Mark expected. However, I expect that some people would prefer to have independent windows for the diffs and merges spawned from their content management system.

Tim

[Zoë]

Mark,

I'm afraid the emphasis for Tim's comments should have been:

So, it’s possible we could support the behavior that Mark expected.

We agree that the behavior you're describing is desirable, but we're considering it an enhancement request, so it's currently lower priority than the bugs we need to fix and the features we still have to get done before the full release.

[mgillespie]

Sorry to drag up this old thread, but I have today installed BC3 Beta (build 452) and it's got what looks like the temp file handlers (Bcomp.exe Bcomp.com) that are described above. Can anyone from Scooter confirm?

I am talking about BComp.com and BComp.exe. In the old days we simply called the commandline parameters on cirrus.exe (now bcompare.exe).

I have removed my /solo switches, and will see how I get on. Initial impressions are that it works, but it was not always 100% repeatable, so I will post back to update.

In the meantime, can anyone from Scooter confirm wether this EXE/COM files serve the purpose mentioned, and what the difference is between EXE and COM versions, and why they are needed at all.

Thanks for the great BC3 product. It's shaping up to be awesome. There is no way I can live with BC2 anymore having used Cirrus/BC3 :-) So much so, I uninstalled BC2 the other week, and have not bothered putting it back on...

[Zoë]

Yes, one of the things BComp.exe/.com is designed for is to allow comparisons/merges from version control systems to open as tabs in existing windows. They're just light-weight processes that spawn comparisons and then wait for notification that the comparison/merge is complete.

The only difference between the .com and the .exe is that one is a comsole app and one's a gui app; they're actually both exes. We need both because if you spawn a GUI app from the console (say from a batch file) it won't wait for the process to finish, and if you spawn a console app from the GUI you'll get a console window with a task bar entry just for the waiting process. Naming them .com & .exe just takes advantage of the cmd.exe search order; if you just use "BComp" without an extension it will run the .com file. BComp.com is also taking the place of the more specialized BCQC.exe we released for BC2.

Technically the .exe version could have been part of BCompare.exe instead, but we needed the console version anyway, and I thought it would be confusing to have multiple BCompare.exe processes running when only one was doing the heavy lifting.