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.
WillFM I'm working up a response.
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.
Tags for this Thread