Jungle IDE and Source Control

Monkey Forums/Monkey Programming/Jungle IDE and Source Control

andrew_r(Posted 2012) [#1]
I'm using the jungle ide in combination with svn source control and one thing I've noticed is that the jungle project file *.jiproj doesn't play nicely with svn...

That is, it has a hard-coded absolute path that means sharing projects amongst developers is a pain if they have a different directory root.
In addition, it seems to change on every save (or it did - I think it does any more).

For source control purposes, it should not have any absolute paths, and should only change if the project structure has changed.

Can I put this in as a feature request? :D

Andrew


ziggy(Posted 2012) [#2]
It does not use absolute paths, except for an internal parameter called "Original Disk Location" that is there to store the original disk location, in order for Jungle to detect projects being moved from one place to another. Other than that, all the file references are relative to the project file, so it should play nice with any good source version control system.
I'm using it on several projects such as Jungle Gui: http://code.google.com/p/junglegui/ and Harpl: http://code.google.com/p/harpl-project/

It can be that SVN can't do a proper merge. It's a very outdated and limited version control system. I would recommend you to use Mercurial instead, it's a lot better in everything, specially on merging changes. (more infor about mercurial in case anyone reading this is interested: http://hginit.com/ )

it seems to change on every save (or it did - I think it does any more).
Yes, it saves to prevent any change being lost. I don't see why this should be a problem, if the files have the same content but different save date, they should merge automatically without any conflict

That said, if you happen to have a jiproj file that does contain absolute references to files, other than the "OriginalDiskLocation" parameter, let me know it, as it could be a very rare bug

EDIT: Ok, I've managed to leave this argument out of the JiProj xml-based document, so it may be a bit easier for SVN to merge JiProj documents on next Jungle Ide version.


Samah(Posted 2012) [#3]
For something that volatile, personally I would put your Jungle project in your .hgignore file.


ziggy(Posted 2012) [#4]
@Samah: It's designed to work properly when included on mercurial. I splitted all non mercurial-friendly settings of a project to the JIPO files. Those files should be excluded but JiProj files can be included on the repository so you get build options and files included/excluded form the solution when working with a team that uses Jungle Ide. Obviously leaving this files out would only require you to manually add/remove or re-reference files to the local project when they're created, deleted or moved, but that's something you should not be manually doing when using Mercurial IMHO. Just my 2 cents.


Samah(Posted 2012) [#5]
If it's a file that only gets updated when you manually change something (like add/remove references in Jungle), I have no problem checking it into Hg, since everyone should (hopefully) be referencing the same files in their project. If it's something as volatile and developer-specific as "currently has X and Y files open", then it should be ignored.


ziggy(Posted 2012) [#6]
If it's a file that only gets updated when you manually change something (like add/remove references in Jungle), I have no problem checking it into Hg, since everyone should (hopefully) be referencing the same files in their project. If it's something as volatile and developer-specific as "currently has X and Y files open", then it should be ignored.
All user speciffic options, such as wich files are open, where the caret is on every file, if the file has split-view on or not, etc are stored in the JIPO file (Jungle Ide Project Options). This is designed to be a local file and should not be included on any version control system. then JiProj file contains infromation about wich files are referenced, and how the compiler is configured for the project, but it does not contain any user specific data.

That said, if you open a JiProj file on notepad or the like, you'll see each document includes an "opened" "cursorpos" parameters. they're there for backwards compatibility but they're NOT udpate and are always the same so they merge always without any issue. In this compatibility area all documents are always closed with caret at first char and at first line. This is done this way just in case someone tries to open this document on a very old version of Jungle Ide, but as I said, this information is arbitrary, always the same and, and ignored by Jungle Ide. It merges automatically always without any difference. This "real" data was moved to JIPO files long ago.

I hope it's clearer now what's stored on a JiProj file and in a JIPO file.

From the Jungle Ide documentation: http://www.jungleide.com/docs/index.htm?Solutionfilesdecription.html


andrew_r(Posted 2012) [#7]
Thanks for taking my request seriously. I personally am not a fan of mercurial and for various legacy reasons prefer SVN. (Maybe because I'm set in my ways :) )

Hopefully the moving of the 'original directory' parameter to the user-specific file will solve my problem.

EDIT: I just noticed that this information is included in the project file for each file...
<Document Filename=".\utils\arrayutil.monkey" Open="false" SplitView="false" SplitIsVertical="false" SplitSize="150">

Are the Open, SplitView, SplitIsVertical and SplitSize attributes the legacy compatibility stuff you were talking about, because they look like user-specific options to me.

Am I missing something, because otherwise it looks like the mere act of opening and closing a file will change the project file and cause an unnecessary version control change?

Thanks
Andrew


ziggy(Posted 2012) [#8]
Andrew_r: Don't be confused by this information. On a JiProj file, this data is always the same and does not reflect the real status of the project. All JiProj files have:
Open="false" SplitView="false" SplitIsVertical="false" SplitSize="150">
This information is a fake information, a placeholder, that grants compatibility with older Jungle Ide versions, but it does not reflect real project status and it never changes and it is always the same. So you don't have yo worry about this.

The real information about which files are open, etc. is actually stored on JIPO files. Those JIPO files should be excluded from the repository, as they represent local user data.

As I've saif, the fact that you're seing this information also on a JiProj file is becouse it's being put there with default values that never change in order to maje JiProj files compatible with older versions of Jungle Ide. I might remove this from JiProj files in the future, but I'm reluctant to lose backwards compatibility on a dev environment like Jungle Ide.