Hybrid View

  1. #1
    Sencha User
    Join Date
    Feb 2012
    Location
    Davenport, IA
    Posts
    30
    Vote Rating
    6
    WillFM is on a distinguished road

      3  

    Default Discussion, Best Practices for Source Control with Architect in a team environment.

    Discussion, Best Practices for Source Control with Architect in a team environment.


    The Problem:
    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.

    Main question:
    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.

    First thought:
    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.

  2. #2
    Sencha - Architect Dev Team Phil.Strong's Avatar
    Join Date
    Mar 2007
    Location
    Olney, MD
    Posts
    1,925
    Vote Rating
    63
    Phil.Strong is just really nice Phil.Strong is just really nice Phil.Strong is just really nice Phil.Strong is just really nice

      0  

    Default


    WillFM I'm working up a response.
    Phil Strong
    @philstrong
    #SenchaArchitect
    Sencha Architect Development Team

  3. #3
    Sencha - Architect Dev Team Phil.Strong's Avatar
    Join Date
    Mar 2007
    Location
    Olney, MD
    Posts
    1,925
    Vote Rating
    63
    Phil.Strong is just really nice Phil.Strong is just really nice Phil.Strong is just really nice Phil.Strong is just really nice

      1  

    Default


    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.

    Your thoughts
    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.
    Phil Strong
    @philstrong
    #SenchaArchitect
    Sencha Architect Development Team

  4. #4
    Sencha User
    Join Date
    Feb 2012
    Location
    Davenport, IA
    Posts
    30
    Vote Rating
    6
    WillFM is on a distinguished road

      1  

    Default


    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?

  5. #5
    Sencha - Architect Dev Team Phil.Strong's Avatar
    Join Date
    Mar 2007
    Location
    Olney, MD
    Posts
    1,925
    Vote Rating
    63
    Phil.Strong is just really nice Phil.Strong is just really nice Phil.Strong is just really nice Phil.Strong is just really nice

      0  

    Default


    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.
    Phil Strong
    @philstrong
    #SenchaArchitect
    Sencha Architect Development Team

  6. #6
    Sencha User
    Join Date
    Feb 2012
    Location
    Davenport, IA
    Posts
    30
    Vote Rating
    6
    WillFM is on a distinguished road

      0  

    Default


    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.

    Why did Sencha decided to take this meta-file approach. Don't most IDE's work with the source files themselves? Its confusing, being on the Architect product page it says "There are no file dependencies. Architect produces regular JavaScript files that you can edit with your choice of IDEs.". I consider as far as moving between the two, the metadata files a dependency, Of course we can use the overload feature, but the overload feature seams more like a crutch then, a meaningful IDE compatibility.

    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.