My security clearance is in the final stage. I don’t know how many stages there are, and considering it’s been nearly a year, the “final stage” doesn’t mean much to me. However, supposedly it’s going to be done in two weeks or so (it’s not the first time I’ve heard that). Before, I was ready to go just to rid myself of that project I WAS working on. But I’ve been switched over to another project until the clearance comes through, and it just so happens to be developing an application using Ruby on Rails. How nice is that? But my time is limited, unfortunately.
There are a lot of things I don’t do that I should when I develop (like use subversion), but I’m hoping I can pick up a few good habits before I head over to Lockheed. I’ve been staying somewhat involved in the project, simply because I love web applications and this one in particular seems pretty cool. I never really worked on it much, but I had several conversations concerning its goals and potential. I’m excited. I’ve been given total control over the interface design, which I should be able to knock out rather quickly. And as always, it will be tweaked throughout the process. That’s the nice thing about working for a small business… creative control. I’m now hoping Lockheed drags their feet on the clearance, but knowing my luck it will come through tomorrow.
01
Chris on Wed Aug 30 at 10:21AM
What?? You’re not using svn?? Have I taught you nothing! :-p Seriously, though, you really should start using Subversion – it’s extremely useful. Actually, it’s absolutely vital for development. And you get started right away since Dreamhost has svn support.
02
Ryan on Wed Aug 30 at 10:52AM
I knew you’d be disappointed. I refuse to put it off any longer, so the next thing I work on, I’ll setup subversion. Mark my words, soldier…
Does subversion have the ability to lock files so nobody else can check them out if I have them checked out? Or is that source control rather than version control? Or are they the same thing?
03
Chris on Wed Aug 30 at 12:26PM
You can lock files, but for the most part it’s not necessary. Subversion will merge different working copies usually without a problem. So, if you modified lines 13-20 of the file, and someone else modified lines 25-30, there would be no conflicts and both changes could be committed without problem.
For the most part, locking is overrated and unnecessary. Really, if you have to use locking… you probably have a management issue – two or more people shouldn’t be modifiying the same methods at the same time.
04
Ryan on Wed Aug 30 at 01:00PM
Good point. I don’t have too much experience with version control, other than “Source Safe” with Visual Studio… I wasn’t promoting file locking, I was just curious. So what if two people modify lines 13-20 of the same file? Just a notification of a conflict that needs resolved? And out of curiousity, how often do you commit your changes? At the end of the day or as soon as you get small pieces working? It seems like the ultimate benefit would be to commit often, so you would have less iterations between versions. I knew a person who would keep files checked out for weeks at a time… that seems ridiculous to me, but I can’t really say since I’m not even using svn yet. I need to get on the ball…
05
Chris on Wed Aug 30 at 01:24PM
Scenario: person A and B both checkout a working copy of the repository (let’s say the revision is 400). Person A changes lines 13-20 and commits the changes. Now, the repository is at rev. 401. But, person B still has 400 checked out. Now, B makes some changes to lines 13-20, and commits. Subversion complains because his working copy is out of date. B runs ‘svn update’, at which point Subversion tells him that the file has conflicts. At this point, there are a number of different files which indicating the changes and where the conflicts occurred. It is then up to B to resolve the conflicts and commit. In Subversion, conflicts basically only happen when a local copy has changes to a line that has been changed in a later revision. When you run an ‘svn update’, svn tells you which files had conflicts.
About committing… you definitely want to commit often. I try to solve small problems one at a time, and commit after each. When you are working on a really big change, you’d want to create a branch, and then merge the branch when you are done. For example, with tinyblog I had a TRY-add-comments branch where I tried out commenting features to see if I wanted them. When I was done, I merged them with the trunk. The cool part was I could still do bug fixes in one branch while adding new features in another.
All you should worry about initially is getting svn working, and learning the basic commands. Since you are on Windows, get TortoiseSVN, but try to learn the actual commands as well (like ‘svn update’). The only thing to watch out for is this – you can’t just move and rename files on your own – Subversion needs to know about these changes so it can track the history of the files.
This is probably the biggest comment ever.