Relative project path #33

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
4 participants
Member

techee commented Mar 4, 2012

OK, this is the last of my 1.5-year-old patches. In addition to absolute path this patch also saves relative path for every open file in the project. When loading, it first reads the absolute paths and if the file isn't found (e.g. the whole project directory was moved), it reads the relative path and tries to open the file relatively to the project file.

techee added some commits Jul 1, 2010

New utils function to get relative path from one directory to another
This is used by the patch that writes relative paths to the project
file. I put it to utils because I use it in gproject as well and
might be useful for others.
Use relative paths in addition to absolute paths in project files
Right now projects cannot be moved to other directories without
losing the list of open files. This makes the project unportable to different
machines because even if the directory structure under your home is
identical, the user name can be different so the paths are different too.

Both absolute and relative paths have their advantages and disadvantages.
Instead of replacing absolute paths with relative paths, this patch
adds one more item into the configuration file for every path. This item
contains a relative paths so both absolute and relative
paths are stored for every file and base path. When the project is read,
first the absolute paths are checked. When the file is not found,
relative paths are used to search for the file. This makes this
implementation backward and also forward compatible with older versions
of project files and geany applications.

For the global session file only absolute paths are used because it is
not expected that this file is moved between directories.
Check for session file bounds in the condition of the loop
The current code crashes when the number is 0.
Member

elextr commented Mar 18, 2012

The problem I have with relative pathnames is that they may pick up the wrong thing when the project file is moved, at least absolute paths work (if only the project file moved) or break (unless you move something into the absolute location again).

I am aware relative paths work well for keeping the project file in the root of the "project" tree, but they are a potential problem if it is located anywhere else.

I would want a warning before trying relative paths and would want all files to come from the same source, absolute or relative.

Member

techee commented Mar 19, 2012

But if you move the project file the files get loaded correctly because absolute paths are read before the relative ones. In other words: everything works like now but just in case the file on the absolute path doesn't exist, the relative path is checked.

I think average user won't be sure what exactly the warning means and what implications it has so IMO it's better to do something which doesn't require user interaction.

The only situation when something incorrect can get loaded requires the following three conditions to be satisfied at the same time:

  • the project file is moved
    AND
  • some source file is deleted
    AND
  • the project file is moved so that the relative path of the deleted file points to some existing file in another directory

IMO the above scenario is rather uncommon.

Member

elextr commented Sep 16, 2012

One example of problems (which is a common use-case) is when a file that is open is outside the "project tree". If the project tree (with its project file) is moved there is no reason to assume that the relative path to outside the project tree is in any way related any more. As I said I understand the use-case within a tree, although Geany doesn't really have any requirement that a project file relates to a tree (although it is a common convention). But without any warning opening a file in a random position relative to where I plonked the project tree is risky for the user.

Perhaps the relative paths could be only used for files under the project base path, that would be safer.

Since we have been deadlocked for ages I have asked Colomban to adjudicate. We should at least get the question answered one way or the other. I expect he will also give you the right or reply.

Owner

b4n commented Oct 1, 2012

I think that better support for moving project files would be a good thing to have; but I'm not sure this is the "best" implementation.

Stop me if I'm wrong, but couldn't we simply store the location of the project file (the .geany) in the project itself, and if a file can't be loaded AND the actual loaded project file doesn't match the saved one AND the missing file is supposed to be found under the directory in which is the project file was expected, try to load the file at relative to the actually loaded project (eg s/oldprefix/newprefix/).
This would handle the case where a project is saved in the project's base path, but wouldn't try to load something like "../../../src/main.c". However, an obvious problem is that if the project file is no in the project's base path but in a sub-directory, the relative paths wouldn't be tried. It could be fixed by using relatives paths from the project base path if the expected project file is under the project's base path. E.g. same as above, but using the project's base path as the reference if the project file is under it.

What I prefer with this is that

  1. it won't try to load relative paths starting with "../", which makes loading the wrong file really improbable;
  2. it avoids saving 2 paths for each open file just to handle the case the project's files gets moved.

What do you think? Is this idea stupid? Does it fails to handle common use cases? Anything?

Member

elextr commented Oct 2, 2012

On 1 October 2012 23:18, Colomban Wendling notifications@github.com wrote:

I think that better support for moving project files would be a good thing
to have; but I'm not sure this is the "best" implementation.

Stop me if I'm wrong, but couldn't we simply store the location of the
project file (the .geany) in the project itself, and if a file can't be
loaded AND the actual loaded project file doesn't match the saved one AND
the missing file is supposed to be found under the directory in which is
the project file was expected, try to load the file at relative to the
actually loaded project (eg s/oldprefix/newprefix/).
This would handle the case where a project is saved in the project's base
path, but wouldn't try to load something like "../../../src/main.c".
However, an obvious problem is that if the project file is no in the
project's base path but in a sub-directory, the relative paths wouldn't be
tried. It could be fixed by using relatives paths from the project base
path if the expected project file is under the project's base path. E.g.
same as above, but using the project's base path as the reference if the
project file is under it.

I would only use relative paths relative to the base path. That is the
only way that will work with the project file outside the base path tree
(the default Geany use-case), and even then you have to edit the base path
in the .geany before opening.

If the project file is in the tree, for it to work automagically after the
tree is moved, the base path needs to be relative to the project file
anyway, otherwise again you have to edit the base path in the project file
before you can open it (and I for one would always forget to do it). Since
the base path and project file are relative anyway, it doesn't matter which
you use, so base path is fine.

And if we only use the base path tree for relative paths we don't need to
know if the project file has moved, saving that additional step.

Then absolute outside and relative inside the base path should be "safe
enough" and still work for the default Geany use-case of the project file
outside the tree.

What I prefer with this is that

  1. it won't try to load relative paths starting with "../", which
    makes loading the wrong file really improbable;
  2. it avoids saving 2 paths for each open file just to handle the case
    the project's files gets moved.

What do you think? Is this idea stupid? Does it fails to handle common use
cases? Anything?

It also just occurred to me that this also interacts with the ML discussion
of separating sessions from project files.


Reply to this email directly or view it on GitHubhttps://github.com/geany/geany/pull/33#issuecomment-9031400.

Owner

b4n commented Oct 2, 2012

I would only use relative paths relative to the base path. That is the only way that will work with the project file outside the base path tree (the default Geany use-case), and even then you have to edit the base path in the .geany before opening.

As you say, it would require to manually update the project's base path.

And if we only use the base path tree for relative paths we don't need to know if the project file has moved, saving that additional step.

Yes we do, otherwise how would we know what's the new base path?

What I originally meant was this: https://gist.github.com/3819447 -- ok, it's not necessarily a really clean impl, but it (should) work.

Member

elextr commented Oct 3, 2012

On 3 October 2012 00:20, Colomban Wendling notifications@github.com wrote:

I would only use relative paths relative to the base path. That is the
only way that will work with the project file outside the base path tree
(the default Geany use-case), and even then you have to edit the base path
in the .geany before opening.

As you say, it would require to manually update the project's base path.

And if we only use the base path tree for relative paths we don't need to
know if the project file has moved, saving that additional step.

Yes we do, otherwise how would we know what's the new base path?

Because its relative, so it automagically moves with the project file, see
project_get_base_path()

What I originally meant was this: https://gist.github.com/3819447 -- ok,
it's not necessarily a really clean impl, but it (should) work.

  1. we don't need all this with relative base paths, and none of your
    examples use them

  2. where do you get the "expected" paths from?


    Reply to this email directly or view it on GitHubhttps://github.com/geany/geany/pull/33#issuecomment-9072367.

Owner

b4n commented Oct 3, 2012

Le 03/10/2012 02:09, elextr a écrit :

Yes we do, otherwise how would we know what's the new base path?

Because its relative, so it automagically moves with the project file, see
project_get_base_path()

Oh, I didn't know we supported relative base paths -- no default project
have one, do they? At least all my project have abs paths here :(

What I originally meant was this: https://gist.github.com/3819447 -- ok,
it's not necessarily a really clean impl, but it (should) work.

  1. we don't need all this with relative base paths, and none of your
    examples use them

You're right, if we always store base_path as a relative path to the
project file (when it's inside it) and we always save files as relative
to the base path (when they're in it), everything would go by itself --
we just need to load relative paths relative to the base path.

If that's actually enough, it shouldn't be too hard to implement I guess.

The only problem I see is that if one moves the project file from inside
the tree to somewhere else, boom, session is lost.

  1. where do you get the "expected" paths from?

"expected" ones come from the project file; the only one we don't have
yet is the expected project file.

Member

elextr commented Oct 3, 2012

On 3 October 2012 11:53, Colomban Wendling notifications@github.com wrote:

Le 03/10/2012 02:09, elextr a écrit :

Yes we do, otherwise how would we know what's the new base path?

Because its relative, so it automagically moves with the project file,
see
project_get_base_path()

Oh, I didn't know we supported relative base paths -- no default project
have one, do they? At least all my project have abs paths here :(

Probably because the dialog defaults to absolute.

What I originally meant was this: https://gist.github.com/3819447 --
ok,
it's not necessarily a really clean impl, but it (should) work.

  1. we don't need all this with relative base paths, and none of your
    examples use them

You're right, if we always store base_path as a relative path to the
project file (when it's inside it) and we always save files as relative
to the base path (when they're in it), everything would go by itself --
we just need to load relative paths relative to the base path.

If that's actually enough, it shouldn't be too hard to implement I guess.

Agree

The only problem I see is that if one moves the project file from inside
the tree to somewhere else, boom, session is lost.

Well any move breaks at the moment, so this is a big improvement, even if
it doesn't address what is probably a rare use-case.

  1. where do you get the "expected" paths from?

"expected" ones come from the project file; the only one we don't have
yet is the expected project file.

Just to summarise:

  1. Only session files below the project base dir should be relative and
    they should be always relative
  2. All others should be absolute


Reply to this email directly or view it on GitHubhttps://github.com/geany/geany/pull/33#issuecomment-9093435.

Owner

b4n commented Oct 3, 2012

Le 03/10/2012 04:50, elextr a écrit :

Oh, I didn't know we supported relative base paths -- no default project
have one, do they? At least all my project have abs paths here :(

Probably because the dialog defaults to absolute.

Yeah, so currently no project would ever have a relative path here
unless the user knew that she could enter a relative path from the
project file
.

The only problem I see is that if one moves the project file from inside
the tree to somewhere else, boom, session is lost.

Well any move breaks at the moment

No, moving the project file alone doesn't break anything at the moment
-- unless one has deliberately chosen a relative project base path.

, so this is a big improvement, even if
it doesn't address what is probably a rare use-case.

Well, maybe, or maybe not. One could have put her .geany in the
project's root, but then want to move it to a subdir, say "projects",
maybe for putting it together with a VCPROJ or whatever.

Member

elextr commented Oct 4, 2012

On 4 October 2012 02:35, Colomban Wendling notifications@github.com wrote:

Le 03/10/2012 04:50, elextr a écrit :

Oh, I didn't know we supported relative base paths -- no default project
have one, do they? At least all my project have abs paths here :(

Probably because the dialog defaults to absolute.

Yeah, so currently no project would ever have a relative path here
unless the user knew that she could enter a relative path from the
project file
.

Well sure, or if they RTFM or the tooltip on the base path entry :)

Which means you are right, almost nobody knows, maybe the tooltip s/b moved
to the dialog, after all its small and we prompt things on other dialogs.

The only problem I see is that if one moves the project file from inside
the tree to somewhere else, boom, session is lost.

Well any move breaks at the moment

No, moving the project file alone doesn't break anything at the moment
-- unless one has deliberately chosen a relative project base path.

Which one should have done when deciding to put the project file inside the
tree, so you don't need to edit the base path each time you move it.

, so this is a big improvement, even if
it doesn't address what is probably a rare use-case.

Well, maybe, or maybe not. One could have put her .geany in the
project's root, but then want to move it to a subdir, say "projects",
maybe for putting it together with a VCPROJ or whatever.

Sure you need to edit base path then, but re-arranging the tree s/b much
rarer than moving it (eg by VCS) so this simple solution handles the major
cases.


Reply to this email directly or view it on GitHubhttps://github.com/geany/geany/pull/33#issuecomment-9112832.

Member

elextr commented Oct 4, 2012

On 4 October 2012 10:42, Lex Trotman elextr@gmail.com wrote:

On 4 October 2012 02:35, Colomban Wendling notifications@github.comwrote:

Le 03/10/2012 04:50, elextr a écrit :

Oh, I didn't know we supported relative base paths -- no default
project
have one, do they? At least all my project have abs paths here :(

Probably because the dialog defaults to absolute.

Yeah, so currently no project would ever have a relative path here
unless the user knew that she could enter a relative path from the
project file
.

Well sure, or if they RTFM or the tooltip on the base path entry :)

Which means you are right, almost nobody knows, maybe the tooltip s/b
moved to the dialog, after all its small and we prompt things on other
dialogs.

The only problem I see is that if one moves the project file from
inside
the tree to somewhere else, boom, session is lost.

Well any move breaks at the moment

No, moving the project file alone doesn't break anything at the moment
-- unless one has deliberately chosen a relative project base path.

Which one should have done when deciding to put the project file inside
the tree, so you don't need to edit the base path each time you move it.

, so this is a big improvement, even if
it doesn't address what is probably a rare use-case.

Well, maybe, or maybe not. One could have put her .geany in the
project's root, but then want to move it to a subdir, say "projects",
maybe for putting it together with a VCPROJ or whatever.

Sure you need to edit base path then, but re-arranging the tree s/b much
rarer than moving it (eg by VCS) so this simple solution handles the major
cases.

Of course if one didn't know about relative project bases then the absolute
project base path wouldn't care about where the project file is :)

Reply to this email directly or view it on GitHubhttps://github.com/geany/geany/pull/33#issuecomment-9112832.

Owner

frlan commented Aug 21, 2013

did not read complete thread ... having a relative path would allow to put project file in VCS. At least I was missing this lately.

Member

elextr commented Aug 22, 2013

@frlan,

It is best to turn off saving the session in the project file if you want to put it in the VCS, otherwise you get commit noise every time you open/close tabs in the session irrespective of relative or absolute paths.

edit->preferences->general->miscellaneous second from last

Owner

frlan commented Mar 9, 2015

Just back on that... merge or close? ;)

Member

elextr commented Mar 9, 2015

On re-reading its hard to follow, but as far as I can tell, b4n made a suggestion to break the deadlock, but it hasn't been done, so no to merge.

@b4n b4n referenced this pull request Mar 29, 2015

Open

Project open changes #450

Member

techee commented Mar 30, 2016

Closing. The way I'd like to go is #450 (once I have time to continue working on it) which makes this patch obsolete.

@techee techee closed this Mar 30, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment