PureBasic Forums - English

Greetings

I wanted to start a small project using PureBasic und put it under version control with Git.
Unfortunately, I noticed quite a few shortcomings and annoyances with the current implementation
of projects within the IDE.

1. The project file (*.pbp) contains user-defined settings
Check out the following XML section from the project file: Such information does not belong in a file that is supposed to be committed. User-specific settings and information
have to be stored in a separate file (e.g. *.pbuser) since other team members will continuously override each other's settings.

2. Code navigation information and general settings are stored in the *.pb file.
Similarly to the above, this behavior is a no-go for version controlling. Here I propose as well
that such information is stored in a non-committed *.pbuser file that can be added to .gitignore.

I know that currently we have the option to have the IDE create separate *.pb.cfg files for
each individual *.pb file. I currently use this solution, though it does unnecessarily clutter
the folder with dozens of files that don't need to be there.


Unfortunately, number [1] renders projects completely useless for me.
If there is a way to change this behavior, please let me know.


Cheers,

Shield

Wouldn't you also have an issue with "CursorPosition" and "Folding" being defined in .pb files?

That's what point [2] says.

Shield wrote:That's what point [2] says.

Yes, I had already formulated my question before finishing your post.

I'm ok with meta data at the end of a file as long as it's not something that would change often, like "CursorPosition" and "Folding". I don't PureBasic's built-in method of project encapsulation, and instead name my "project" files with the prefix "prj.", so I depend on the current behavior of storing compiler options.

Mistrel wrote:[...] so I depend on the current behavior of storing compiler options.

Well that's fine, I'm not asking for the removal of this option. I'm asking for a possibility to store
all this meta information in a file that is not supposed to be committed in the VC system.

Considering that all of the project options are disabled by default, why not remove the arbitrary metadata (line number/folding) and add a checkbox to the Compiler Options page for "save options to .cfg file" or something; and if the cfg file is there then read it, otherwise use the meta-data.

This way you don't have to use the global "save to .pb.cfg" option when you only want it on a per-file basis.

I agree with what @Shield sayd:

Shield wrote:1. The project file (*.pbp) contains user-defined settings
Check out the following XML section from the project file:

Code: Select all

<section name="data">
    <!-- edit: paths are also not platform compatible. -->
    <explorer view="C:\Users\*user*\*project*\" pattern="0"/>
    <log show="1"/>
    <lastopen date="2014-11-21 10:10" user="*user*" host="*host*"/>
</section>

Such information does not belong in a file that is supposed to be committed. User-specific settings and information
have to be stored in a separate file (e.g. *.pbuser) since other team members will continuously override each other's settings.

and I'm facing the same problem with Git. Definitely more options on what to include/exclude in project files would make it easier.

Did you come up with any solutions?

I've been wondering if a (rather ugly) solution could be to have some script remove <lastopen ...> line before commiting -- to avoid at least sharing personal machine/user info. Would this give problems in opening the project? If this solution works it could be added to the IDE Tools, and have it execute at save time.

I didn't realize also paths were problematic... Doesn't PB IDE handle path formatting differences between OSs? I would have though that when opening a project it could fix that.

Another solution (a cleaner one) would be to have some custom script/app to generate a parallel project configuration file (different name or extension) were unwanted data is purged and paths are fixed. One could then use .gitignore file setting to commit only the sanitized version of the configuration. Possibly, this would mean settin PB IDE to use a non standard project extensions (like @Mistrel's ".prj" -- but as extension, not prefix) and leave ".pbp" for the purged version (so that repository files will contain a standard project file).

Anyone has ideas on how to solve this?

If I get around to find some solutions I'll post them here...

What about a custom project configuration syntax?

Maybe the whole issue of versioning PB projects could be approached by developing a custom cross-platform project configuration file syntax, and a tool that could translate these syntax files into standard .pbp files.

Ideally, this tool could rely on PB's native Preference library, or JSON, to export/import project files into a middle-format designed with version control and cross-platformness in mind. I am not sure about the details, but basically it would have to resume data about a project's settings in a way that will ensure a proper .pbp file will be reconstructed from it. It shouldn't be too difficoult, and the app could be integrated in PB IDE Tool's.

From what I've read on other posts in the forums, the IDE automatically rebuilds the .pbp files during work, so fields like lastopen & user & host should be filled in by the IDE (since they wouldn't be exported to the alternative project files). Of course, this requires some practical testing (on all platforms) to verify how the IDE actually handles all this.

Someone has already attempted to "tamper" with .pbp files, confirming that the IDE auto-rebuilds them:

http://www.purebasic.fr/english/viewtop ... t=pbp+file

and seems like any non-standard data will be removed by the IDE during sanitation. So the only path to go for this would be to adopt a parallel standard for project files, with version control in mind.

Any thoughts on this?

This problem of sharing project files on GitHub has haunted me for a while now.

I've come to the conclusion that the best way to handle it is this:

Add to ".gitignore" the following:
So that "*.pbp" projects are ignored, but not "*.sample.pbp" files.

The idea is to copy your working project file from "<filename>.pbp" to "<filename>.sample.pbp", and then strip away from the latter all personal-info and local-project entries (history, paths, etc.). Ideally, one should build a PB IDE tool that can do this automatically for you, so when the project is first created (or its settings changed) the tool will create/update the "<filename>.sample.pbp" file.

End users of the Git project will then copy "<filename>.sample.pbp" to "<filename>.pbp" and use that to work locally, and because the latter will be gitignored all save-time changes to the file will remain strictly local.

The only problem is that if there are significant changes to the original project file, the end user will need to update the local project file to take on the changes of the "sample" file — again, a smart IDE tool should also offer an update functionality.

I've written an article on the Git related problems with PureBASIC projects:

http://htmlpreview.github.io/?https://g ... index.html

hopefully this might be useful to those interested in the topic (the article link above is a live preview of an Alpha-stage project I'm working on, whose developement has slowed down lately, but hopefully when it's ready it will be publicly shared and also be viewable as an online website).