// Note to the reader: Although the primary purpose of this blog is to keep a running dialog of lessons learned and pros/cons of the Software Paradigm project, it almost seemed necessary to include some of the general team experience as well.
Having been out of the pure development world (professionally) for a while, it's always fun to get back into the roots of where I began. Through the progression of this course, we ended up writing code for assignments that needed to be submitted to a centralized location for the professor to grade. The version/source control system Git (and its subsequent site GitHub.com) was the chosen method to use.
While the learning curve was not too high in getting things running with Git, most of the options of usage were limited to the command-line world (nothing wrong with that, so far). As long as it was a one way interaction (i.e., 1 student pusing their code/homework up to one Github repository), things were working with minor issues.
However, as the team project phase began, it became quite apparent that there were issues with Git, at least in our usage of it. With our team of 3, we found that multiple people working on files started to produce some errors through Git along with conflicts that didn't seem to be easiliy resolved. The lack of a GUI took out some checks and balances which started to increase with every change that was made.
Certain errors started to creep up consistently, such as the infamous:
The only resolution that would work was to completely delete your entire local working version of the entire project, and do a clean git clone from the server. Obviously, this was not a solution that could be maintained, but just a quick troubleshooting technique as you could not actually work on anything because you had to completely wipe your files just to download the updates made by your teammates.
There also was no consistency between systems or people in getting these errors. A wide variety of environments are being used by the entire team from Windows XP/7 to Ubuntu and other flavors of Linux with similar results.
After much frustration, the team came to a unanimous decision to port over the entire project to Google Code, which utilized the SVN source control system. With easy integration into all flavors of environments that the team is using, we were able to find SVN client tools and have been working on the actual project since, instead of managing the source control aspect.
It looks like some tools might be well suited for the solution, but if the troubleshooting curve is much larger and ineffective than the actual goal, then alternatives will have to be visited.
Having been out of the pure development world (professionally) for a while, it's always fun to get back into the roots of where I began. Through the progression of this course, we ended up writing code for assignments that needed to be submitted to a centralized location for the professor to grade. The version/source control system Git (and its subsequent site GitHub.com) was the chosen method to use.
While the learning curve was not too high in getting things running with Git, most of the options of usage were limited to the command-line world (nothing wrong with that, so far). As long as it was a one way interaction (i.e., 1 student pusing their code/homework up to one Github repository), things were working with minor issues.
However, as the team project phase began, it became quite apparent that there were issues with Git, at least in our usage of it. With our team of 3, we found that multiple people working on files started to produce some errors through Git along with conflicts that didn't seem to be easiliy resolved. The lack of a GUI took out some checks and balances which started to increase with every change that was made.
Certain errors started to creep up consistently, such as the infamous:
error: Untracked working tree file '/path/to/some/file.scala' would be overwritten by merge.
The only resolution that would work was to completely delete your entire local working version of the entire project, and do a clean git clone from the server. Obviously, this was not a solution that could be maintained, but just a quick troubleshooting technique as you could not actually work on anything because you had to completely wipe your files just to download the updates made by your teammates.
There also was no consistency between systems or people in getting these errors. A wide variety of environments are being used by the entire team from Windows XP/7 to Ubuntu and other flavors of Linux with similar results.
After much frustration, the team came to a unanimous decision to port over the entire project to Google Code, which utilized the SVN source control system. With easy integration into all flavors of environments that the team is using, we were able to find SVN client tools and have been working on the actual project since, instead of managing the source control aspect.
It looks like some tools might be well suited for the solution, but if the troubleshooting curve is much larger and ineffective than the actual goal, then alternatives will have to be visited.
No comments:
Post a Comment