Showing posts with label SVN. Show all posts
Showing posts with label SVN. Show all posts

Friday, September 10, 2010

Started @ CDOT

This fall, I am a "Student Research Assistant" at CDOT. It's a wikkid title because it sounds like it belongs to a university student. However, as one of the administrators explained it, we are not researching for the sake of knowledge--we are researching for the sake of a final product.

The first thing I did was set up my workstation. Sounds easy enough, but when you throw in a MAC OS (which I'd never worked with before), it's new*2.

Some things I learned:

sudo su

1) I should've set up my account on this computer under the admin account in the first place.

2) I utilized the sudo su command while setting up my github account (as outlined in Anna's blog). (github is a version control system.) sudo is a command that lets you execute commands as a super user.

Since everything was done at the command line, as user donna, I was prompted for a password every now and then and then inevitably told that "donna is not a sudoer" (or something like that). The fix was to beat the cl to the punch and just type in sudo su and then type in the admin password, and off I went.

(Must mention that even while under Admin account, I had to sudo su in order to access other user's accounts).

github

As I already said, github is a version control system. In one of my classes, OOP344, I used Tortoise SVN, and that was fine because it had GUI. Since Anna's instructions were on the command line, that's how I worked, too. It was frustrating =\

After cloning the repos that I was going to be working with, I created a local and a remote branch (again, instructions are in Anna's blog), but I stumbled a bit. Things I learned:

1) When branching, make sure you are in the directory that contains the cloned repo. So when you clone popcorn (one of the repos I will be working with) like this:

git clone git://github.com/mozilla/popcorn-js.git popcornDonna

follow with cd popcornDonna, then create the branch (git branch firstBranch).

2) As Anna says in her blog, some errors that result in creating a remote branch (using the git push command) are fixable by editing the config file. She is referring to the .git/config file.

How to find the file: make sure you are in the folder that contains the repo you cloned (in my example, the folder is popcornDonna). Then type ls -a . One of the results should be .git. Change directory to .git (cd .git). Type ls and you should see the config file. Edit it.

So far so good, tho. Just going to be reading up on Popcorn and learning some JS for the time being.

Wednesday, February 17, 2010

OOP344: Creating an editor

Before things get any more hectic with this OOP344 project (in which we're to create a programming editor, a la vi), a few things:

1) Compiling can be a pain in the butt

I have never compiled anywhere besides linux (on Seneca's matrix server) before, so learning to compile on Visual and Borland was a frustrating experience. More than anything else, it was being told that the library I was trying to #include did not exist.

To compile on Borland, I first had to create a batch file that would add to $path the path-file to my Borland compiler. I still have not figured out a way to set this permanently, so for now I must run it everytime I need to use Borland. It's a simple .bat file with one line:

set path=%path%;C:\Borland\BCC55\Bin

I had to create a bcc32.cfg file in the Bin. All it contains is:

-I"c:\Borland\Bcc55\include"
-L"c:\Borland\Bcc55\lib"

It cuts down the typing I have to do when compiling because it automatically includes the libraries I need to run my program.

Visual and Linux were easier, though with Linux, I forgot to "-lncurses" at first.

2) I'd been accidentally committing to trunk all along

What I'd done was copy and paste the PRJ file (which contains the .c's and .h's for the project) from trunk to my workspace. I thought that because it was in my workspace, committing any changes I made was ok. I was under the impression that anytime people committed to trunk, everyone's version of similarly named files in trunk would be updated, too. After all, how else is everyone going to get synched?

This issue has been fixed now. I've done a fresh checkout, and after all the editing I've done to my code, I'm going to be ready to merge my code with the trunk code soon.