Discussion, Best Practices for Source Control with Architect in a team environment.
The company I'm working for, have started a rather large project, which is going to live on Ext, for the most part. Getting started, were finding it a difficult task, to work with source control (in our case Team Foundation Services). It would be easy enough, for one developer, As they could just check out the entire project, and avoid, saving/deployment issues with Architect. (TFS locks files you don't have checked out) and architect, tends to always at the vary least save, app.html, and several meta files, every time you save. We also have set up the deployment, to deploy, to a parallel directory, were our Server side code is (ASP.NET MVC). Were having a vary hard time, checking code in, out, without completely over writing, someone else changes. or check in's failing. in this case because, in order for concurrent development, developers have had to "unlock" there folders, which TFS, does not check in these files in, because they weren't thought to be checked out in the first place. it does note that there different, in the logs, but does not handle them in a vary strait forward manner.
So my question, to you guys is, how do you currently implement Architect, and Source control in your team environments, and what suggestions would you make in how we could improve ours. and which files have you found necessary, to keep in/out of source control.
Some idea's I've had, is to just do the GUI in Architect, and do everything else in another IDE. But several of the developers are new to ExtJS, and Architect is an annoying, but great learning tool.
So the easiest question to answer here is that we currently use Git and Github for our source control.
We'd love to hear where the major pain points are. What's not merging most often?
At the end of the day like all editors Architect produces files. The important files are metadata which tell Architect all about the project. These files are in fact just JSON which should be fairly merge-able provided 3+ engineers haven't made changes to it all at the same time and then will take some human intervention.
I've heard this argument before but every day we're adding more features that will make this less and less valid. An example is that when you upgrade projects from framework N.1 to N.2 we make several passes through to ensure your code is updated to the latests APIs. We're also adding loads of smarts to update event listeners and controller actions when parameters change so you don't have to. Furthermore the code editor is going to morph into a more productive tool on each major release getting more and more out of your way while aiding you even further.
It's my job to make Architect less and less annoying! ;p 2.2 is looking like a major leap forward in responsiveness including the code editor. Typing at max speed should feel more fluid. I can't give a way all our secrets, but I think you'll find developing in Architect will pay dividends.
I have a feeling perhaps I'm not addressing the real pain point so more information on that is helpful. Is the issue that you don't know which files to checkout? If files are marked as read only I do know that Architect will warn you that it could not save certain files.
Finally, I'm going to have Bruno chime in and give some feedback on how he and a large team are managing a very large project in Architect.
Down the road, once we've gotten, things in a semi working state, have most of our views, models, stores, defined, and decided on the best controller structure, I don't see this being a huge problem. but right now, getting started, over the past few weeks. There's many of points, where all of us, might have made changes to the same controller. And with how Architect currently, keeps the files into memory (which i understand is supposed to be changed in the future, in detecting changes), It's hard to, for example using TFS, to have one person check in a file, and another "get latest version" without loosing changes they might have made to the same file.
We originally started using git, on prior projects (VB, C# in Visual studio), but found, that its merge tools were difficult to use, especially in tandem with keeping dependencies/ binary files (outside of the build process), without huge merge conflicts that were hard to solve.
On a side note, are we going to see code completion in Code View, and in line property editing in "read only" Code View?
Ah, the churn of a new project! I do want to know if it's easy/med/hard to understand the meta files and how to merge conflicts? Anything that could be done to make it easier?
Oh boy you know a lot about potential future product features!
Git and binaries = bad
Some have stopped checking in binary files and just check in their hashes. This allows you to detect changes to them. Others simply use SVN for binaries and git for all else. Anyways the point of this post isn't to convince you of one VCS or another.
2.2 will see improvements to how Architect handles outside file changes. Other features I'm unable to reveal to much as we don't have a public road map.
Merging conflicts, is not so much hard as it is tedious. Though I can't say I have run into any actual Merge conflicts myself, in regards to the meta files.
As far as understanding the metadata, file. the meta files are structured in a reasonably understandable structure, though some kind of reference to more obscured parameter names (Eg.: cn, codeClass, what designerId guid represents). which could be helpful, in solving certain merge conflicts.
What benefits did you see by using the metadata structure, as apposed to, the raw code, and what prevented it from being done in a detached manner?
More on topic though, I'm looking forward, if he will, to Bruno's feedback as you mentioned earlier.
p.s. any criticism is, meant to be constructive. I mean no disrespect, Your product is great tool, and I look forward to seeing it grow.
My team is having the exact same problems/struggles. We use Microsoft Team Foundation Server (TFS) for version control. We develop all of our server side code in Visual Studio and Sencha Architect for the UI. We had to create (as the OP mentioned) a parallel "sencha" directory to store the architect files and another directory within the Visual Studio server side project to store the output files from sencha architect as the VS project is what is published to production. We have to manually check files in/out hoping not to overwrite another devs changes because architect doesn't recognize changes to local files or read-only flags.
We still have not found a good solution. For now, we first have to place the sencha architect solution in a central location so that both devs have access to the same project. Publishing is directed back to our local TFS projects where we have to manually check-out the file being worked on via TFS. All team members have to agree on when to check-in the sencha architect project into TFS.
A big pain point and struggle right now. Single dev, no problem. Two or more... not so good.
The problem here is, that regardless if you edited a file or not, All the meta files are regenerated when you save the project.
So, Everything returns an error saying it failed to save.
Not to mention, being the "locking" metaphor that TFS uses. makes it extremely difficult. with meta data, to, confirm, if your file in fact did save, with this wall of text hitting you when you save. even if you knew exactly what meta file you edited, and prior to saving, had gone into Team Explorer, and checked out said file, so the person could write to it in the first place.
I guess most of us, are just used to working in an environment, where if you edited a file in Visual studio, it would automatically check out the file for you, or warn you that another person already has the file checked out, on the fly. instead of manually having to check out the file. Maybe there's a way with TFS, to set it up, to use a merging metaphor, for the folder, the project sits in, instead of a check in check out metaphor.
If you guys are willing to troubleshoot the issue in house, I'd suggest setting up a test server, with TFS Express, its free, and will give you working environment, to see first hand the issue's were having with it.