Review Request 109317: Don't upload/download the file project if it's local

[Aleix Pol Gonzalez]

On March 6, 2013, 10:59 p.m., Aleix Pol Gonzalez wrote:
> > Alas, I don't think this is a proper fix for the bug. The same thing can happen with actual remote projects. We should simply do a synchronization "every once in a while" or maybe even whenever the apply button is clicked in the project config dialog (or something else in the kconfig-object is saved).
> > 
> > I also don't like treating local files differently to remote ones here, KIO makes this all completely transparent and thats a good thing and all other places
> > 
> > I don't have strong objections though, so if it fixes an annoying bug and you can move the above object-creation I think it can go in.
> 
> Aleix Pol Gonzalez wrote:
>     TBH I don't love it either. I agree that KIO should make it transparent, although I think that for this to happen KConfig should be the one using KIO, and not ourselves.
>     
>     I think the bug is annoying enough (I'm sure all of us have hit it at some point) to try to put a solution.
>     
>     An alternative I can think of, is adding a IProject::syncDeveloperConfig that calls sync and syncs the files. I'd be ok with that too, even though it adds a very specific API which is not nice either.
> 
> Andreas Pakulat wrote:
>     Hmm, that requires touching several places, in particular the cmake plugin which writes to the config without going through the project-config-ui. I dislike that more than having local-files special-cased, so as I said just fix the statJob assignment and I'm fine with it.
>     
>     In the end, I think exposing the KConfig object as public API might have been a bad idea, maybe we should've just exposed some set and get API taking a list-of-groups, a key name and a value. That would give the shell code full control over when syncing is necessary and it could be done in a central place...
> 
> Aleix Pol Gonzalez wrote:
>     Well, KConfig eases the integration with KCM's, I think it's ok.
>     I'm unsure though, if we should care about too much ::sync() calls and SSD devices...
>     
>     Right now we have far too much sync's in the cmake code, at least.

Just checked, it's just the cmake code, so I can reduce the amount of sync's there and it's ok.


- Aleix


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109317/#review28736
-----------------------------------------------------------


On March 6, 2013, 7:30 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109317/
> -----------------------------------------------------------
> 
> (Updated March 6, 2013, 7:30 p.m.)
> 
> 
> Review request for KDevelop and Andreas Pakulat.
> 
> 
> Description
> -------
> 
> See the bug attached.
> 
> It's of no use that we keep sync'ing the config files if they have to be moved around in the end.
> 
> What this patch does, is to not have a developerTempFile and instead use the actual developer config file (the .kdev4/*.kdev4) to read/write configurations, in case it's a local project.
> 
> 
> This addresses bug 291983.
>     http://bugs.kde.org/show_bug.cgi?id=291983
> 
> 
> Diffs
> -----
> 
>   shell/project.cpp b0fb221 
> 
> Diff: http://git.reviewboard.kde.org/r/109317/diff/
> 
> 
> Testing
> -------
> 
> Restarted some kdevelop cmake projects and it seemed to work.
> 
> Also tests didn't stop working, although it seems unlikely that anything depends on that.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130308/6d0bfb56/attachment.html>