[Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

[...]

> >
> > Are all settings saved on apply? not just the prefs/project prefs ones?
>
> I doubt we make a difference when saving the config file -- since as you
> said yourself saving only a part of a keyfile isn't that easy --, but I
> don't know for sure.
>

I didn't mean that only part of the file was changed, I meant that the
configuration save is triggered by *all* the dialogs and menu items that
can change settings, for eg unless I missed it, the set build commands
dialog doesn't trigger a configuration save after an ok (though it does
save filetypes).


>
> >  I thought there were some that still didn't for one reason or another,
> > maybe that should be changed as a separate thing anyway, in which case
> > you are right, the "rush" only applies to session data.
> >
>

Every UI or programatic change to a setting needs to be checked that the
configuration/project is saved, unless you have already done that?

I agree that we should do that but its another discussion, although it does
affect this one.


[...]

> > If the save happens its unlikely to be a problem so long as
> > its on a local disk which isn't full.  If the project file is on a
> > network share or worse still, on a ftpfs/sshfs/httpfs file system then
> > lots can "go wrong" and the chances are increased by periodic saving
>
> Oh dear, configuration on an unsafe remote.  OK, that's an argument why
> saving config periodically might not be that safe -- although normally a
> network failures would result in *not* saving the file, not corrupting
> it (given that we use an atomic write like g_file_set_contents()).
>

For project files in the tree it is reasonable that they may be on the
remote, and well, on those funny file systems, g_file_set_contents()
doesn't work :(

My cunning? implementation puts the session file in the user config
directory, which *hopefully* is local, or at least on a fast reliable
nfs/samba share.


>
> > (not to mention potential performance issues).
>
> Well, performance issue is inherent to periodic saving, it being session
> only or whole config doesn't change anything.
>

But only the session needs to be periodically saved, and that should be
local in my split implementation.


> [...]
> >     > For project sessions just using another file in the same place as
> the
> >     > project file is more of a problem since project files can be in the
> >     > project tree and some people like to save them in VCS.  So users
> would
> >     > have to make sure that their git.ignore (or whatever the other
> VCSes
> >     > use) is edited each time so that the session file isn't saved in
> the
> >     > VCS.
> >
> >     I agree with Dimitar, if somebody is able to add a file to a VCS she
> >     must be able *not* to add that file.  Is there *any* VCS around that
> >     adds files without asking before, unless explicitly told so?  Nobody
> >     sane will do `git add .` or `svn add .` for committing changes.
> >
> >
> > Well, git add is part of the normal workflow, editing .gitignore isn't.
>
> Yeah, but you *choose* what you add, you don't add the whole project
> directory but maybe on the first import.
>
> >  But I guess if the project file is being stored in VCS then you would
> > expect .gitignore (or whatever svn etc use) to be edited already to
> > exclude .session and .gitignore to be stored in the VCS as well.
> >
>

What I mean here is that I agree that putting a session file in the same
directory as the project file isn't a big issue.


> >
> >[...]
> >     PLEASE, no.  This is IMO the easiest solution to make the fix worst
> than
> >     the issue.  Not removing files would leave more and more useless
> files
> >     (not an option), and cleaning is almost impossible to do well -- your
> >     proposition might remove actually used sessions as easily as having >
> >     MAX_SESSION projects (not an option either).
> >
> >
> > Heh, heh, I was going to just say, sort by access time and delete the
> > oldest one before creating a new one, but then I remembered that all my
> > disks are mounted noatime :)
>
> Even if access time was reliable you'll never know how many project
> files one has, and you can't rely on the user changing some weird magic
> value for them not to loose session data.
>

I wasn't being so complex as you seem to think, I was just saying keep the
last N project related sessions, like the recent files list, we could even
use the recent projects list and only keep sessions for those?


>
> >     > This proposal isn't about a proper session management capability,
> >     > there isn't one that works on enough platforms to be worth
> including.
> >     >
> >     > Any thoughts welcome.
> >
> >     Reading my mail above, I see it might sound like I think $subject is
> >     just a bad idea.  No, I think it would be a quite good thing, and for
> >     weird people adding project files to their VCS [1] would be most
> >     welcome.  I also think that separating session and settings will
> >     probably help to someday improve the settings sharing between
> instances.
> >
> >     The only problem is that I don't see immediate and tremendous gain,
> and
> >     that I don't like the proposed solution -- not that I have a better
> one.
> >
> >
> > Damn! The point of starting the thread was to see what other
> > implementations there are :)  If I thought it was a perfect solution I'd
> > have made a PR by now :)
>
> No no, what I asked was "why is $subject useful?", because I thought
> (and somewhat still think) that the arguments weren't for $subject but
> for "periodic save" ;)
>

Heh, yeah the two issues are a bit mixed,

1. as I said to Dimitar, the main reason for the proposal is to put
projects in VCS without the noise from session data while still allowing
users project sessions.
2. any possible improvements to the reliability of session saving via
periodic save or even save on file open/close are a secondary (but still
useful) by product.


>
> >      On the first point, I'd be happy to be proven wrong though, maybe I
> >     just don't see the light.
> >
> >     Regards,
> >     Colomban
> >
> >
> >     [1]  Yes, I don't really see the point.  OK, the settings we have in
> >     project files might be useful for the project.  Indentation type &
> with,
> >     and EOL style.  First two are saved in each file by well known
> editors
> >     (vim, emacs).  Generally when people put project files in their VCS
> it's
> >     because those project files are used as build system too.
> >
> >
> > Yes ATM the main use-case is build system settings,
>
> Hum, what I meant that our project files *are no* a build system, so the
> current use case I see is only indentation settings and maybe line
> ending settings.
>

I don't understand what you are saying here, the project files *do* store
build commands, if your project uses different tools, eg scons not make,
then that is stored in the project file and gets restored in Geany whenever
you open the project file.  This is *very* useful and is the original
reason I extended the Geany "build system" back in 0.19.  And having that
information in a project file in VCS distributed with the project source is
then *very* useful as well, but ATM you have to turn off project sessions
to avoid lots of noise commits, and so we are back to the original reason
for the thread :)

Cheers
Lex


>
> Cheers,
> Colomban
>
> > but that could also change if it was easier to share project files.
> >
> > Cheers
> > Lex
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20121003/ce5f18ab/attachment.html>