[Updated 10 Nov 2006]
I’ve just started learning how to use CVS on Linux with KDevelop, and there are enough gotchas that I thought it might be interesting to share what I’ve learned. I have used lots of source control in the past, but never CVS. RCS [ages ago], QVCS [windows front end for rcs], and VSS with Visual Studio.
Serious coding on Linux means that I need source control, so I had a look at what’s available. CVS seems to be the long-time standard for open-source projects. But SubVersion is new on the scene, relatively, so I took a look. But after a little study of a few doc pages, including this one, it looks like SubVersion has the nasty habit of suggesting, if not requiring, that your directory tree look in a special way for SubVersion use. That, and the fact that the SubVersion GUI client for Linux looks like it is in its pretty early days, has lead me to choose CVS and Cervisia. Any Open Source code base with a version above 1.5 has got to have seen a fair amount of use.
So, here are my experiences with SUSE 10.1, KDevelop 3.3.5, Cervisia 2.4.5. I chose to build a local repository that is file based rather than a server based repository.
- Install Cervisia and CVS. All on the original distro.
- Figure out how to create a CVS repository. Turns out that Cervisia Repository >> Create… works. Note that CVSROOT will be created inside of that folder. So don’t end the path in CVSROOT.
- At this point you cannot use File>> Open Sandbox. To open a sandbox you must have done an Import and a Checkout..
- I was nervous, so I backed up my KDevelop project folder which already was in play. Then use Repository >> Import.
- The parameters to Import are a little tricky. The Respository path does not end in CVSROOT so it is
/home/darrell/Development/CVS in my case, not
- The module is a name that will be applied to the entire import, so a lowercase project name without spaces and no extension is appropriate. I used khexwin for example. This should be the same lower case name as the project folder.
- The working folder for Import is the project folder. For Checkout it will be something different so beware.
- I just used wwc and release for the tags and left the rest blank for now.
- You should see success when you import your project.
- At this point I would suggest you rename your project folder to myprojectORIG and then
- do a Repository >> Checkout…
- The Repository folder is the same as before
- The module is the same as before
- The working folder will be the containing folder, not the project folder. So if your project path is
/home/user/Development/project then you will want to use
The project will come from the module name. If you want to change the folder, then you can put a new name in Check out as:.
But KDevelop will freak out if you do that, at least I don’t know yet how to recover from a change in the project path. The project will need some adjustment to build if the path is changed.
- Don’t forget to check Recursive checkout.
Warning: KDevelop gets very upset if you change the path of a project. There is probably a way to recover after you move a project, but I don’t know what it is. So you will have to check out your project to exactly the same path as you created the project, or all hell will break lose and the project will not build.
- After the checkout you should be able to use KDevelop to open the project and build it. All should be well. If the path of the project has changed, use Build >> Clean Project, followed by Build >> Run Automake & Friends and Build >> Run Config.
- Cervisia can now do a File >> Open Sandbox… since there are CVS subfolders in the checked out tree. I have not turned CVS support on in KDevelop. It looks like you can check files in/out in the AutoMake panel on the right. I haven’t seen other places that light up with checkin/out menu items.
- I just use Cervisia to commit files. If you are working alone like I am, you won’t have to merge or update based on other folks work.
I had some issues:
As I mentioned, KDevelop has problems if you change the path to the project. I’ve reported a BUG and posted a forum topic to get clarification about how to get a project to work after it is moved.
- When I tried to check in the files after I changed them, I was getting errors about a sticky tag – release – that was used to Import the project. I took a branch to solve this. Use Advanced >> Tag/Branch… But I think a better way would be to just add a new tag rather than a branch. At this point I have merged the branch into the main branch so things look a lot more sane.
- Be sure and set the Recursive setting when doing a commit so you can just checkin from the top of the project tree.
- Use Update [?] often from the tool bar to see what you have changed. The coloration of files is pretty obvious and very helpful.
Looks like CVS / Cervisia is working for me now.