Hi Esenthel,

I saw this recent feature :

Quote:-added support for exporting application source code files as raw text files (without converting them to C++) via new menu option "Export/Text"

Would it be possible to have the import from text ?
It is important for us because our source codes are versionned with SVN, and the text format that Esenthel could use is really important.
Thanks !

That sounds very reasonable.
As you've mentioned it would allow for code syncing via SVN, which I understand that many people would welcome, since EE does not yet have manual verification and editing of code syncing conflicts.
I'll add this for the next release

Could you tell me however, would it work by importing .txt files from the same path that currently the files are exported? _build_/AppName/Source/*.txt would that path work? Because in this path there's also lots of other temporary files, like *.cpp, *.h, and also that path can get deleted by the "build/clean" and "build/clean all" menu options

Or would you need me to use a different path without any other temporary files which won't get deleted by the "clean" options?
I could then use something like that:
"_svn_/!#1ksq679hg41r3jtk!p4jq-/^2fp27-on^64_87qdelc!3t!.txt" (where the "!#1ksq679hg41r3jtk!p4jq-" is the ProjectID and the "^2fp27-on^64_87qdelc!3t!" is the source code element ID)
or
"_svn_/ProjectName/Folder/File.txt" with human readable names (this is easier to read, however it won't work so well if you suddenly rename/move to different folder a source code element)

Thanks for considering my request

Quote:Could you tell me however, would it work by importing .txt files from the same path that currently the files are exported? _build_/AppName/Source/*.txt would that path work? Because in this path there's also lots of other temporary files, like *.cpp, *.h, and also that path can get deleted by the "build/clean" and "build/clean all" menu options

I think using the same Source directory isn't a problem even it's "polluted" by temporary files. If a tip tool display the information with the import/export features in the editor, explaining that only these .txt files should be versionned and used

Quote:Or would you need me to use a different path without any other temporary files which won't get deleted by the "clean" options?
I could then use something like that:
"_svn_/!#1ksq679hg41r3jtk!p4jq-/^2fp27-on^64_87qdelc!3t!.txt" (where the "!#1ksq679hg41r3jtk!p4jq-" is the ProjectID and the "^2fp27-on^64_87qdelc!3t!" is the source code element ID)
or
"_svn_/ProjectName/Folder/File.txt" with human readable names (this is easier to read, however it won't work so well if you suddenly rename/move to different folder a source code element)

Using a different folder might be a solution... We should find a common name for the different cvs/svn/git-like softwares.
Now, I think the second idea is much better than the ID-names... It would improve the communication in the team when talking about a source code...

"- Hey, I've just added a few new functions in the .. wait... !#1ksq679hg41r3jtk!p4jq-/^2fp27-on^64_87qdelc!3t!.txt file
- Which class name is this in the editor ?
- Let's me open it... Spell_object class
- Ok. What is the name of the text file again ?
- God.. I just closed the window. Wait..."

I understand that if the files are renamed/moved into folders in the editor it will be hard to trace them. Wouldn't be easier to concatenate the folder-hierarchy in the FileName.txt, and having them in the same directory ? Of course it'll have to be handled with SVN with a delete/add file... But it's already has to be done this way with a simple move...

Why not :
ProjectDir/RawSources/DirectoryInEditor_FileName.txt

I've just finished implementing this:
3 options will be available in next release "Build/Export/SVN" -> "Explore, Import, Export".

For the moment I went only with this naming system:
"_svn_/!#1ksq679hg41r3jtk!p4jq-/^2fp27-on^64_87qdelc!3t!.txt"
Because typically you won't need to manually edit/preview those text files, you will just select the whole folder and press synchronize/commit in the SVN tool.

Once next version is released, please give it a go and let me know how it works.

Greg, why don't you let users use their own version control systems? I mean right now, also because all the code files are renamed to unique identifiers, using a version control system like Subversion is just not feasible. But the thing is, using Subversion is really necessary for professional projects.

My suggestion is the following:
Leave the filenames of all assets intact and manage the unique identifiers in another way (for example have a project configuration file in which you link the files with the UID's).

Another solution would be to really complete the server by adding version history and practically everything that SVN provides. But I guess this is way too much work and adds another layer of maintenance that (I believe) you don't really need.

Will this still use the same cryptic filenames?
I think this won't be feasible then. Developers don't only use SVN to just "synch" the code. They want to review the changes, check against specific revisions or just explore the revision history.

Greg, why don't you let users use their own version control systems? I mean right now, also because all the code files are renamed to unique identifiers, using a version control system like Subversion is just not feasible. But the thing is, using Subversion is really necessary for professional projects.

My suggestion is the following:
Leave the filenames of all assets intact and manage the unique identifiers in another way (for example have a project configuration file in which you link the files with the UID's). And disable code synching altogether.

The issue being discussed here is unrelated to using EE 2 with a versioning system. He is implementing a feature to export code to TXT files. The more advance features of versioning are moot anyways with EE 2 because the data is a proprietary format and versioning systems wouldn't be able to decipher it.

@Rubeus: But the only reason he wants to export it to text (and back) is to use SVN. You wouldn't need an "export to text" feature for anything else. All this is a hack.

But the solution is simple.
Just leave all the files in their original format (code=text) and let the users deal with the versioning. Everyone has different requirements and what Esenthel does is forcing a very limited system onto their users, which is not helping getting more developers to use it.

Esenthel Editor/Server will support version control in the future for both codes and assets, this will be the recommended way.
It will take some time, so before waiting until that's finished, I've simply added "SVN" functionality (available in next release) to Export code to text files, which you can then synchronize with 3rd party SVN tools, and Import it back to the project.
The functionality is very simple and straightforward.

@MrPi I fail to understand how can you call this a hack/limited system, especially when you haven't even tried it yet.

Again, like I've said at the start, there will be more code syncing built-in functionalities in the future (integrated in the Editor), for the moment I believe that new SVN import/export functionality will work just fine.

@Esenthel: Well, right now it is very limited, isn't it? There is no version control yet. So developers have to manage their assets somewhere else, creating an additional layer of complexity. And I'm calling the "export to text" feature a hack, because it's a way around a problem, a bypass.
Please don't take this personally, it's just my input to the issue.

I saw you implemented the SVN functionnalities, but what about the consistent file name ?

Would it be at least possible to identify the sub-project files ? For the MMO example code, it would be :
- Server
- Client
- Shared

Up in this topic !

It is quite complicated to log/understand the SVN history with the encrypted names...
Would it be possible to have the exported name as : "ApplicationName_CodeFileName" or ApplicationName\CodeFileName?

Thanks

Hi, sorry, right now I'm a bit busy with other features.
Unless you'd be willing to make a small contribution for that, 50-100$
Thank you

I've remembered that you can do that manually using Editor Network Interface.