Getting the current active project

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 02.04.07 18:27:36, Matthew Woehlke wrote:
>> Andreas Pakulat wrote:
>>> On 02.04.07 17:38:18, Matthew Woehlke wrote:
>>>> Andras Mantia wrote:
>>>>> On Saturday 31 March 2007, Andreas Pakulat wrote:
>>>> or, better 
>>>> yet, have a way to locally cache frequently-accessed files and/or files 
>>>> that can't be remote (i.e. Andreas' point again) and push them out 
>>>> either asynchronously in the background, and/or on project close.
>>> Well, writing the configuration files back only on project closing is
>>> one of the easiest and fastest solutions.
>>>
>>> While writing back on configuration change seems "cooler", it may be a
>>> problem, think of slow-links and also the IProject carries its own
>>> KSharedConfig::Ptr to a local cache which would need to be re-fetched
>>> from remote every time its accessed. The problem here is that there's no
>>> easy notification possible between KConfigSkeleton (which would do the
>>> reading/writing of configuration for the dialogs) and IProject.
>>> Basically because they don't know each other and there's no 3rd object
>>> that knows both.
>> My thought was that you "own" your project, any changes made from 
>> elsewhere just get clobbered. Especially since the general consensus 
>> seems to be that projects should not be shared anyway. :-)
> 
> Well, I wasn't suggesting that 2 people work with the same remote
> project at once. I won't implement that, because then we'd more or less
> have to invent our own vcs-system. But see the answer to Andras,
> re-parsing can be done from the local cache (which needs to be in sync
> with the remote files of course), it may still slow down kdevelop, not
> sure how fast KConfig is on re-parsing.

Agreed; I was never saying that local cache shouldn't be used. I was 
just suggesting that we *might* want to asynchronously push any changes 
out to the remote store... If this isn't practical, that's fine, it was 
only a thought.

>> My main thought with the async (in which case slowness wouldn't matter) 
>> was more to push changes out in case something catastrophic (like, say, 
>> a power failure) happened to your local machine, so that less would be 
>> lost. But it was just an idea, not something I think is "necessary" by 
>> any means. :-)
> 
> Well, if your PC looses power while just before or while the upload
> happens you're screwed with any approach I can think of.

Hmm, true, I guess you would need some sort of backup system?

Anyway, the idea is you would be less screwed if, say, (like me) you 
almost never close KDevelop. So, if I open KDevelop, and over the course 
of a week or so make some changes, and then lose power, I just lost a 
week of changes (ok, they are project changes so it is unlikely this is 
much more than an inconvenience). If changes are pushed asynchronously, 
I would lose maybe my last few changes, but less than if changes are 
only pushed on close.

Of course this assumes also that the local cache can't be recovered 
(maybe it is on tmpfs), otherwise it is no worse than what would happen 
with a local project.

-- 
Matthew
Obscurity: +5