Metadata should be more version control friendly
Hey Aaron and Phil,
Wondering what the status is on this.
Just for reference, we are two developers using Architect for a medium-sized project; about 10 major view components, 7 models, 6 stores, and 6 controllers with about 10 functions each. We commit to our own branches in Git and merge them into a shared 'dev' branch every day or so. I believe we are one of the first organizations to use Architect for a complex project beginning-to-end, and one of the firsts to buy licenses for this 2.0 version.
Our major issues come during merges:
1. ImplHandlers and tpls should be stored with real line breaks.
Git's built-in merge tool doesn't appear to be able to work with the implHandlers defined in the metadata for each function. It simply chokes on any conflicting change whatsoever, leaving us to manually merge the contents. Obviously this is quite a job considering the implHandlers are not stored in a way that is particularly human-readable.
2. Local data should stay local.
The XDS and metadata should not include attributes like "expanded" or "expandedState". These change constantly during development and cause endless issues. They muck up diffs and cause merge conflicts when the expanded state of a component is changed in one branch, and an entire component is moved in another.
3. Architect should reload the project when metadata on disk changes.
We have run into completely lost commits on multiple occasions when merging each other's changes and forgetting to restart designer. If I merge in a change from our other dev, then do anything at all in Architect that requires a save, Architect will rewrite all the metadata from memory and cause my next commit to revert all merged changes. Simple polling of all metadata files with a "Disk contents have changed. Would you like to reload the project?" dialog would do wonders.
Unfortunately merges are getting to be such a pain in Architect's current state that we have discussed dropping it for most of our project and instead using it only for simple View work - a text editor is much better for working with Controllers, Models, and Stores, as the Architect editor (while improved) is still lacking in many fundamental areas (tabbing, searching, performance). Our merges have become this problematic.
We are not exactly excited by the prospect of dropping Architect as you cannot jump back onto the plane once you have jumped off - I have not heard that any capability for reverse-engineering an ExtJS project is on the roadmap. I am hoping you can give us a reason to stick around.
Funny that you should post this today; we just discussed point 1 re: implHandlers and 2 re: expandedState earlier today in our sprint planning. Both of these will be getting some love in the next few weeks.
Great to hear Aaron, thanks for the response and please keep us updated if you can.
Thanks for the fix!
Originally Posted by aconran
Tags for this Thread