On Thu, Jun 30, 2011 at 11:40 AM, Lex Trotman
<elextr@gmail.com> wrote:
I'm sure you had a very embarrassing interview with someone about why
you broke the production server and are very annoyed with yourself,
i didn't actually - the marketing people who complained got the generic technical explanation that a software bug caused it.
especially as the full file path shows in the title bar ('aint I a
Nobody who works with a document-editing tool reads the titlebar on a regular basis.
shtinker rubbing it in...:-) but my point is that no matter how we
store filenames they may point to unexpected places when you move
stuff, and relative files doesn't fix that.
It does if one does NOT use .. in the path names: use names in the form a/b/c or /a/b/c. i have implemented this in my own software and know it to be reliable. Storing relative paths ".." in them is just downright dangerous.
[...]
> i've been programming professionally for going on 20 years now, and i have
> _never_ seen a source tree which has files from _outside_ the source tree
> managed by build/project files within the source tree. Not one single time.
> i challenge you to show me one high-profile (i.e. not only on your hard
> drive) project where such a constellation exist.
Well I top your experience by at least 10 years and I have seen many
project layouts which are forests not single trees, as I noted in a
previous post. It is a perfectly normal thing for builds to manage.
But such forests are (A) managed under a single common root or (B) they are are not managed via a single project file (i.e. not by IDEs).
The problem here is simply the session records rather than anything else.
Right.
1. session files which are the concern of the individual programmer and
2. project data which does go with the project tree.
Amen.
As Matthew pointed out there is a use-case (and a common one from past
user input) where project files don't go in the tree, they live in the
users ~/projects. In this case the sources are probably not under your
project file so relative is irrelevant, its back to absolute.
And i believe that such a use-case lies in the realm of gnome-text-editor instead of an IDE. IDEs are (traditionally) designed to manage specific source-based projects, not OS-wide collections of arbitrary trees.
Its actually we big system people who tend to have the need to keep
project data in the vcs, and who have the control over the projects to
be able to do it. Can you imagine approaching Linus asking to put a
Geany project file in the Linux vcs? or any GNU project? or ... so in
all these cases the project file is user local outside the tree.
If i was hacking the /usr/src/linux i would drop (or symlink) my .geany file into that directory. Problem solved. With the current behaviour, my project file will be invalid the next time i upgrade and get /usr/src/linux-X.Y.Z+1.
i'm not convinced that having the project file outside the repo provides any benefit or any safety against path-related errors. Not only that, but it challenges common conventions (unsuccessfully, it turns out).
And when the project file is outside the tree then absolute makes sense.
Then store those as /a/b/c instead of a/b/c. Problem solved.
On Thu, Jun 30, 2011 at 11:51 AM, Lex Trotman
<elextr@gmail.com> wrote:
On 30 June 2011 19:21, Joerg Desch <
jd.vvd@web.de> wrote:
> On Thu, 30 Jun 2011 10:42:02 +0200
> Stephan Beal <
sgbeal@googlemail.com> wrote:
>
>> i've been programming professionally for going on 20 years now, and i
...
> Same here... ;-)
But hobby-wise going on 30 years - since 25 December, 1983 :). My first line of code was something like:
CALL CLEAR