Sign into the programming account or make one if your team doesn’t have one. This is so that everyone can access the same Google Drive folder on their computers locally.
Download the backup program for google drive from the settings button.
(If you already have it, then click on the backup icon and sign into another account.)
Make note of the location of the backup folder that Google Drive made
Setting Up Eclipse
Create and switch workspaces by clicking on file, then switch workspace, then other.
Browse and navigate to the Google Drive folder for your programming email.
Click on it and Eclipse will set it up as your workspace.
Open up the Eclipse project in the Google Drive folder.
Everything is set to go!
Whenever you save a file, it is automatically updated to Google Drive. If team members are on eclipse while another team member is working, then they just need to refresh. Don’t work on the same files at the same time because that will probably lead to someone overriding someone else. Just make sure to be communicating all of the time.
NOTE: Create a new Robot project on the new workspace and work off of that. Also, for the libraries from WPI, put the WPI folder into the project folder on the Google Drive folder. Then, you can set the build path to the jar files of the WPI libraries right inside your own project. This will make it so that people don’t have build problems.
Seems interesting, but what exactly do you not like about GitHub? Most things you do should be via Git commands (CLI or GUI or whatever Eclipse has) anyways, and you can avoid interacting with the GitHub website as much as you want.
Additionally, you can always use a different Git repo hosting service like GitLab or BitBucket if your complaints are GitHub specific.
:rolleyes:]
The best version control is:
Robot
Robot2.0
Robot2.1
RobotFinal
RobotFINAL
RobotREALLYFINAL!!
RobotACTUALLYTHELASTONENOMORECHANGES
Robot3.0
/:rolleyes:]
GitHub/GitLab/BitBucket gives you line-by-line changes, allowing you to (usually) avoid issues associated with trying two people trying to work on the same file at the same time.
GitHub/GitLab/BitBucket is, in my opinion, a much better thing to use for programming for two main reasons. You can have multiple different ‘branches’, allowing different people to work on different things in parallel without breaking each others’ code. Also, you generally will see it used in the professional world. Look at GoogleAWSNvidiaApple etc etc etc.
First of all, the whole point of Git is version control. This means that if you make a bunch of changes to code, across multiple files, and then want to revert them, you can easily do so. Google Drive does allow you to revert to a previous version of a file, but it doesn’t have any way to revert a multi-file commit. You could keep a list of which version were changed when, but then you’re just recreating Git.
Second, Git has branching. You can work on something new without having to commit to master, which should always have working code. You can then use the merge tool to add your new code to the master branch, which is especially useful when people have made other changes to master in the meantime. Git will let you compare any files that differ and choose what should be kept.
Basically, Google Drive may be nicer to use. But you will be in for a lot of pain and hardship when you need to fix bugs.
This is an interesting topic. I am looking forward to tomorrow’s FUNdamentals because though I use GIT in my personal Android programming, I cannot figure out how to get it to work with Labview. We just keep running into merge errors.
For now, though we know it is not the way, we are stuck with flash and Google drive options. This is worsened by the fact that in Labview, renaming a project is not enough either, because often, it is he support files ones changes.
Thanks. I tried using the first tutorial, and it worked fine until merges from different computers had to come into play. Then, all chaos unsued. I will look at the second diff tool.
Git is a version control system, it works off changes, not the file as a whole. For that reason, people can have different forms of the same project at different points in the version timeline. This ‘inconsistency’ is designed to be merged to upstream when the feature is finished and stable, for everyone else to them pull down into their local copy. This makes each set of changes isolated. The advantage of this is that if multiple people are working on the same part of the code at the same time, they don’t affect each other, and will be merged together when stable, with conflicts resolved if necessary.
Git is not a ‘realtime’ collaborative system, it’s a tool used for codebases with many contributors working on it, tracking each change by each person and doing so in a sane manner. Using something like Google Drive, you’ll quickly find why version control systems like git are so widespread and trusted.
I can completely relate. When I first learned Git, the commands were quite a bit confusing. Here are a few links that might help. Though, I can echo what the rest have said I really think that git is worth the learning curve you will definitely appreciate it learning it in the long run
Once you have the repo setup, you really only need to know:
$ git status # tracks file changes since the last commit
$ git add . # adds all changed files to commit. Or instead of the "." (dot) put the specific names of the files you want to commit
$ git status # verify that the files were added (they will be green)
$ git commit -m "Descriptive commit message goes here"
$ git push origin master # your upstream should have been setup in the initialization process could be BitBucket, GitLab, or GitHub, among others
I hope there aren’t any teams out there being lead down the wrong path by your frankly awful advice. Google drive may be more user friendly but it is also 100% not designed for software development and version control. Perhaps a moderator could delete this thread to limit the damage?
Here at 2898, we found git doesn’t quite meet our ease of use criteria. After all, some kids have been driving robots since middle school. So, we figured, why not develop a system kids have been using since birth? We decided upon a technique we refer to as G.I.T., or General Intelligence-based code Transmission. Rather than relying on difficult and unintuitive software, we simply have our programmers remember all of the code they are working on, typing it from scratch whenever they switch computers. After all, there’s no point in writing code if you’re just going to forget what you wrote a month later. This has the additional benefit of resulting in far more interesting merge conflicts. Instead of having to learn things like “merge strategies,” we simply lock them in a room and let the best programmer win.
Shoutout to Brendan from team 1458, who has worked with us from the very beginning to pioneer this revolutionary version control system.
While this is a creative use of google drive you need to remember this is not what google drive was designed for.
Google drive is basically designed around what you are telling people not to do, its a platform that enables live collaboration. If you are set on using Google look into Google Cloud Platform. There is a free trial but it also states that you can upgrade to a “paid account” so I’m not sure about all the details. The fact that Google has a product alongside Drive for this exact problem should be a major indicator that Google Drive is not intended to be used for version control. Again creative solution and if it works it works. If you are still planning on using Google Drive just be very careful syncing things and who has access to what.
While were at it RIP Google Code, you never stood a chance.
TLDR: I see you found a square peg that fits a round hole so don’t expect a perfect fit.
