Inadequate Project Structure for Version Controlling

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
User avatar
Shield
Addict
Addict
Posts: 1021
Joined: Fri Jan 21, 2011 8:25 am
Location: 'stralia!
Contact:

Inadequate Project Structure for Version Controlling

Post by Shield »

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:

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.

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
Image
Blog: Why Does It Suck? (http://whydoesitsuck.com/)
"You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly."
- Linus Torvalds
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Re: Inadequate Project Structure for Version Controlling

Post by Mistrel »

Wouldn't you also have an issue with "CursorPosition" and "Folding" being defined in .pb files?
User avatar
Shield
Addict
Addict
Posts: 1021
Joined: Fri Jan 21, 2011 8:25 am
Location: 'stralia!
Contact:

Re: Inadequate Project Structure for Version Controlling

Post by Shield »

That's what point [2] says. :)
Image
Blog: Why Does It Suck? (http://whydoesitsuck.com/)
"You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly."
- Linus Torvalds
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Re: Inadequate Project Structure for Version Controlling

Post by Mistrel »

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.
User avatar
Shield
Addict
Addict
Posts: 1021
Joined: Fri Jan 21, 2011 8:25 am
Location: 'stralia!
Contact:

Re: Inadequate Project Structure for Version Controlling

Post by Shield »

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. :)
Image
Blog: Why Does It Suck? (http://whydoesitsuck.com/)
"You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly."
- Linus Torvalds
Mistrel
Addict
Addict
Posts: 3415
Joined: Sat Jun 30, 2007 8:04 pm

Re: Inadequate Project Structure for Version Controlling

Post by Mistrel »

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.
User avatar
Tristano
Enthusiast
Enthusiast
Posts: 190
Joined: Thu Nov 26, 2015 6:52 pm
Location: Italy
Contact:

Re: Inadequate Project Structure for Version Controlling

Post by Tristano »

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...
The PureBASIC Archives: FOSS Resources:
User avatar
Tristano
Enthusiast
Enthusiast
Posts: 190
Joined: Thu Nov 26, 2015 6:52 pm
Location: Italy
Contact:

Re: Inadequate Project Structure for Version Controlling

Post by Tristano »

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?
The PureBASIC Archives: FOSS Resources:
User avatar
Tristano
Enthusiast
Enthusiast
Posts: 190
Joined: Thu Nov 26, 2015 6:52 pm
Location: Italy
Contact:

Re: Inadequate Project Structure for Version Controlling

Post by Tristano »

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:

Code: Select all

*.pbp
!*.sample.pbp
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).
The PureBASIC Archives: FOSS Resources:
Post Reply