[Github-comments] [geany/geany] session_split branch long term issue: applicability to projects (Issue #3015)

[xiota]

> > Store the session part elsewhere... so that the remaining project part is largely static and invariant across systems, so that can be checked in.
>
> But does anyone actually want to check in that?

Apparently @kugel- does.

> To be specific, when this change happens, will we, developers of Geany, want to have the project file checked in the Geany repository?

1. Maybe.  Depends on how it's implemented.
2. Geany devs deciding not to use it this way doesn't mean *all* other developers also won't.
3. This isn't the only benefit of the config/session split.  It is just one of kugel's motivations.  A couple possibilities:
  + Multiple configs could share a session or multiple sessions could share a config.  This depends on implementation and the scheme I suggested would need to be modified to support it.
  + Options could be stored in different config files with some files overriding others.  (@elextr has mentioned being able to change "any" setting in projects...)

> And I assume that one of the reasons why you store your project files outside the project directory is that it isn't version-controlled so you actually aren't a user of such a feature anyway.

I store projects in a centralized location so I can easily switch among them.  I'm not against checking in a project file if the issues are resolved.  If a suitable project file were version controlled, I'd be able copy or symlink it.  This makes new-project creation easier for new users because they don't have to do it at all.

* Projects are not version controlled now because they're cluttered with personal settings, absolute paths, and frequently changing settings that aren't suitable for being shared across multiple users.
* Even if I don't use projects a particular way doesn't mean others won't or that I won't in the future.

> > There could be an option to not split the session from the project. In that case, relative paths would continue to work.
>
> Either do it or don't do it for everyone - having to deal with settings that are hard to explain to users and having to maintain 2 different modes of session storage isn't exactly what Geany needs.

Different people have different preferences, so I am for having more options, provided the program logic they control is not too complex.  The current config/session split implementation is likely not the end.  With appropriate changes, preferences could very easily be moved around in different files.

> > Project files could contain a copy of the hash to enable locating and moving old session files.
>
> This is probably the only sane option but then you are facing problems like sharing session files by 2 different projects when you have one original_project and make its copy to project_backup - both will then share the same session files.

* I would guard it with an option because it affects version control.  (The hash would be stored only if the option is enabled.)
* The hash for different projects would be different.  When the project file is copied to a new location:
  + Geany would recognize that the stored hash differs from the generated hash.
  + Geany would locate the old session file via the stored hash and copy it to a new file using the new hash.
  + The sessions for the two projects would then be allowed to diverge.

For moving to a different computer, I suggested having a preference to store the session in the project file.  If you don't like having the option, you don't have to use it.

> Geany is a simple editor, we should come up with simple solutions that are easy to reason about and easy to explain to users.

Simple?  Have you seen the [74-page manual](https://www.geany.org/manual/current/index.html)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3015#issuecomment-980484967
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20211126/4f68ffee/attachment-0001.htm>