Thank you for reporting this bug. We will make it our priority to review this report.
Not ready for team collaboration?
Is there a way to provide "user settings" outside of the XDS?
Our team is evaluating using Sencha for our platform going forward, and we work accross a variety of configurations.
Currently it appears that when a dev updates the XDS from source control, we must everytime go in and alter the exportpath. This is a pain.
You should be able to provide a pointer in the XDS project file to a local config that overrides the settings in the XDS. The local config wouldn't get checked in and thus overwritten by the last guy who changed the path and committed to source control.
Maybe I'm missing something obvious... hope so... please let me know how we're supposed to use this in a team environment. I've read the "Collaboration" information that I could find, but it doesn't mention anything at this level.
Other than that - Architect2 is an incredible piece of software. I hope it will work out for us. I can see myself spending many years in this IDE
23 Oct 2012, 10:03 AM
User settings are written to a file called .architect (and typically excluded from source control).
The export path is currently a project level setting. We can look into migrating it to a user level setting and/or allow the user level setting to override it.
23 Oct 2012, 10:49 AM
the .architect file
We can coordinate the paths on our end for now at least where the OSs are the same. Its a few seconds every time after updating - not super critical - but it would be great to consider it for the .architect file. Thank you for the quick reply
I may have found a way to sort out export path issues between colaborative teams working on different systems. Do the following:
Originally Posted by jasonehle
Create a project. Save it, export it (with your own path to your deployment area). Then if you are using svn or git or whatever, push it as is to the server where the team can pull it to their own systems.
The team member has to do the following: Pull the project, go inside the project folder, copy the xds file, rename it to his/her own name (for example: joesoap.xds). Edit that file in a notepad and change the name property to "joesoap" (in this case). You can choose to edit the exportPath property here, or using the sencha architect.
The idea is that Joe Soap will use the joesoap.xds file to work on the architect, and the others can use their own files. Ultimately if you add a component when using joesoap.xds, it will reflect into the other files as well. So you CAN push and pull using some sort of versioning! The only issue I have is merging issue, but I am sure git, svn or other versioning solution can assit there..!
I hope this helped...