Learning source Depot

 I remember asking my manager about the technology used in Microsft Excel projects and what skills would support me during my internship experience. I was glad to know that the primary programming language we would use was C++; however, I was surprised that we would use a new version system called source depot, which is different from Git. Source Depot was a completely different source control that I needed to read about before my internship. My primary goals were to learn how to commit, push, pull, and merge changes and the similarities and differences between Git and Source Depot that I can leverage when researching Source depot. 

Unlike Git, a distributed system with local and remote repositories, source depot is a centralized version control system with a central repository and client mappings to that repository. Another significant difference is how Git has terminal and graphical user interfaces(GUI) options, but Source depot is accessed through the Command-line option. When I was learning how to collaborate on the same branches using Git, I preferred to use Git’s GUI version to understand changes to my version history. It was a steep learning curve to learn the many different commands used in Source depot without switching between other interface options. 

During my first three weeks of the internship, I spent a lot of time going through some courses offered to interns and new hires to ramp up on different skills. During these courses, I utilized my previous knowledge of Git to understand how Source depot worked while noting the difference between the two. Although there is still a lot to learn about Source Depot, at least my team has collaborated on our project’s branch with few merge conflicts.

Comments

Post a Comment

Popular posts from this blog

Software test engineering career

During the last two weeks, I talked to a couple of full-time employees to learn how Microsoft tests its software and a career option as a Software Test Engineer. Test engineers write software tests like unit tests, sub-system tests, scenario tests, and vendor tests. Unit tests are tests written to check how different functions or methods work at the lowest level of abstraction. During a conversation with a former Test engineer, I learned about Test-driven development, where test suites are developed before the actual development of the product. Although test-driven development is highly encouraged, some engineers write tests to verify their product's functionality after the coding. One importance of Test-driven development is fully understanding various edge cases to consider while developing. Sub-system tests are tests written to cover code shared between different components. A specific type of sub-system testing called cross-platform testing verifies how code behaves on other E...
Read more

Lesson from overcoming a challenge

 I spent most of the week reviewing comments on my code review and preparing for demo presentations of the end-to-end customer experience of our feature. During my last demo presentation, I remembered how overwhelmed I felt during my first week at the internship. Everything from understanding my project description, adjusting to work in Pacific Standard time when physically located in Berea, and trying to understand the meaning of the C++ code in Excel's codebase seemed a lot to understand. By taking one task at a time and reaching out to my mentors and manager whenever I needed help to understand something, I overcame my technical and non-technical challenges. One major challenge I faced during my internship was executing my second project task. My task was to enable customers to navigate to a specific sheet and cell in Microsoft Excel using deep linking. To deep-link to the customer's cell location, I worked with code from the front and back end of SharePoint's server, wh...
Read more