 |
| Frontier Kernel Lab Notebook |
|
|
|
|
|
|
Discussion Membership
|
Adding files to the Frontier CVS repository
In a previous lab note, I documented how I used WinCVS to download the latest CVS updates. However, if you're going to send changes back to the SourceForge repository, you need an SSH key. While WinCVS seems to be able to do some of this, most of the docs list Unix-style command-line commands. In this lab note, I was originally going to look at how to send changes back to SourceForge using command-line commands but then I found another application, TortoiseCVS, that seems to make the process very easy. Get enabled as a Frontier developer in the Frontier Kernel project First, you'll need to be enabled as a developer for the Frontier Kernel project. One of the project administrators will have to enable you. Make sure you've got a SourceForge account and then send a note or post to the project admins. When you go to http://sourceforge.net/projects/frontierkernel/, you'll see a list of the project admins in the upper, right corner. Generate your SSH key and get the authentication agent PuTTY is a free telnet/ssh application. I originally thought I'd be needing PuTTY itself, but it turns out you really only need two supporting applications: PuTTYgen and Pageant. Those applications are available from here. Download PuTTYgen.exe and pageant.exe. PuTTYgen generates your SSH keys, and pageant automates your login and access to SourceForge for secured sessions. To actually generate your key, follow the specific (and really easy) directions here. There were two areas that were initially unclear. First, the directions seem to ask for what looks like an email address for the Key comment field. I put in my SourceForge username, followed by an @ sign, followed by shell.sf.net (as in davidgewirtz@shell.sf.net). Second, the directions specify a passphrase in the Key passphrase field. I just made up a password. Once you've generated your key (which will have both a public and private component), you'll save the private key to disk (this is clearly described in the above docs), and post your public key in your account maintenance page on SourceForge. It's a bit of a hassle logging in and finding the fields, but it shouldn't take more than about five minutes. Note: according to SourceForge, it can take ten minutes or so for the keys you've uploaded to become active. So go get some coffee. At this point, you're done with PuTTYgen. Close it. Using Pageant to secure your sessions You'll want to configure Pageant to help you set up your sessions. It looks like you may want to put Pageant into your Startup Items to have it automatically connect you into the repository. Full directions on configuring Pageant are here. Pageant winds up in your system tray. It's a got a cute little icon of a computer with a hat on it. Right-clicking on the icon gives you a menu. Although there are menu items for creating a new session, all you're really going to need to do is select the Add Key menu item and open the key file you saved back when you used PuTTYgen. One note: although Pageant automatically loads, I've found I've had to reopen my key each time I've restarted the box. You may need to do the same thing. Make sure Pageant shows your key in the key list (select View Keys from the menu) before you try doing any CVS trickery. Installing TortoiseCVS Download and install the TortoiseCVS application here. It'll add some items to your right-click context menu in Windows Explorer. Here's how the Web page explains it: With TortoiseCVS you can directly check out modules, update, commit and see differences by right clicking on files and folders within Explorer. By the way, one of the more inexplicable features of the TortoiseCVS application is that it has a good, clear Windows help file. The file is understandable, has screen images that match the application, and is useful. This is an open source project with a UI that's clearly and accurately documented. That's just creepy. Checking out the Frontier Kernel as a developer Because of the need for secure access, even if you downloaded or checked out the Frontier Kernel using anonymous CVS as I documented in my previous lab note, you'll need to do it again with a secure protocol. As you may recall, I'm keeping my Frontier source in my My Documents folder, in the directory F:\My Documents\Frontier\. This may not be good practice, but I have automated backups of My Documents, so it's a way to make sure this is also backed up. When CVS does a download, it downloads into the <module name> subdirectory of the directory you specify. So, since the CVS module we'll be downloading is Frontier, I'll be using just F:\My Documents\ with TortoiseCVS. This is very easy. Just right-click on the My Documents folder and select CVS Checkout from the context menu. A dialog box will be displayed. You'll want to specify the following line in the CVSROOT field (with some changes): :ext:davidgewirtz@cvs.sourceforge.net:/cvsroot/frontierkernel Obviously "davidgewirtz" is my SourceForge user name. Once you've been enabled as a developer, you'll want to use your SourceForge user name here. Notice that, unlike what was specified in my last article, the protocol we're using is :ext: rather than :pserver:. That's because :ext: is the secure shell protocol using SSH. Important: Don't forget to specify the module as Frontier at the bottom of the dialog. And make sure to capitalize Frontier. Once you click OK, you'll get a security alert from PuTTY. Read the message and if you agree everything's ok, go ahead and hit OK. Unless CVS has a cow (see below), everything should download correctly. Why CVS had a cow In my first try at this, CVS decided to have quite the cow. My guess is CVS decided to do this either because I'd gone in and modified a bunch of files as part of my attempt to add a new set of verbs, or because I'd already done an anonymous CVS download. I took the easy way out. I renamed my Frontier folder to Frontier-old, and just did a plain vanilla checkout. I didn't make all that many modifications and I documented everything anyway, so it was just easier to start clean. I repeated the instructions above, this time with a clean, empty Frontier folder, and the secure download worked flawlessly. Using TortoiseCVS to add files back to the repository I started this whole CVS process because I added a new folder to the Frontier module: build_VC2K3. Inside that folder were a few files that comprised the new Visual Studio .NET 2003 project files. The next step, now that I created that directory, was adding those files back to the CVS repository. This is far easier than you'd expect. But before I tell you how to go about sending those files back into the repository, let me tell you about a mistake I made that caused all sorts of confusion. Learn from my mistake, young Jedi. I used the procedure described below to add a the build_VC2K3 directory and its files to the repository. Weirdly, the new build_VC2K3 directory didn't get added, and the files in it got added to the build_VC6 directory. This was very confusing. I thought I'd used the TortoiseCVS program wrong and I went nuts trying to figure it out. Then Andre pointed out what I did wrong: Just a guess, but did you start out by making a copy of the build_VC6 directory and renaming it to build_VC2K3 rather than creating an empty build_VC2K3 directory an copying the needed files from build_VC6 over? In the first case, you would have also copied the CVS directory over where cvs does it's housekeeping, including saving information about where the parent directory is located in the repository and which files in it are actually under version control. I suspect that when adding the Visual Studio files, that's why they ended up in the build_VC6 directory. If my hunch is correct, try the following to start over: First, create an empty build_VC2K3 directory, then move the project files for Visual Studio .NET into it. Yep. That's what I done did. Oops. To remove the incorrect files, I had to do an update on the build_VC6 directory (which means, in TortoiseCVS, to right-click on the build_VC6 directory and select update). This downloaded the files that were now in there, including my wrong files. Then, for each file, I right-clicked and selected Remove from the CVS menu. Finally, I right-clicked on the build_VC6 menu and selected Commit. So, now that I've created a new directory from scratch and have just the files I wanted, here's the simple procedure:
That's all there is to it. Well, sort of. If the items you're adding conflict with the items someone else is adding, TortoiseCVS will give you some error messages. You'll have to resolve the conflicts (read the TortoiseCVS manual) before you'll be able to make the changes go back up to the repository. Again, TortoiseCVS's excellent help file will clearly explain what you're supposed to do to clear things up.
|
|
||
|
