I have created this issue to that we can close off the review and deal with this separately.

--------
We have a problem: during the project wizard there is no way to make your context. There is likely another problem too: browsing is meant to be fast, so relying on a local persistent checkout to do it may not work so well?
Daniel Ostermeier 4 weeks, 1 day ago (October 1st, 2008, 2:54 a.m.)
Well that is a problem, since there are no alternatives that I have found :(. Will take this out of this review and add it to http://jira.zutubi.com/browse/CIB-1662
Jason Sankey 4 weeks, 1 day ago (October 1st, 2008, 10:51 a.m.)
Maybe browse shouldn't get a context, or maybe we just document that it may be null. Either way the restrictions on browse need to be well documented. At least it is bonus functionality rather than required.
Daniel Ostermeier 1 week, 1 day ago (October 22nd, 2008, 10:04 p.m.)
The awkwardness is that we then need to be able to recognize if browse is not available if the ScmContext is null. We would rather not show the browse link rather than returning nothing after all.
Allowing the capabilities to change based on the context would resolve this. IE: during the wizard, getCapabilities(null) would not return the BROWSE capability since Git can not browse without a context. How does that sound?.
Jason Sankey 1 week, 1 day ago (October 22nd, 2008, 11:59 p.m.)
The general idea is appealing, I am just unsure of the consequences of this. Can we pass a context everywhere we check capabilities? Do contexts change over time, meaning we would have to check capabilities more often? Would this make any cases awkward, where it is possible for an SCM to be capable at one point in time but not later? Maybe I am worried about nothing, I haven't reviewed the use of capabilities. If there are problems, though, I am happy enough to just say browsing gets no context for now, as it is not a critical operation at all.