Fog Creek Software
Discussion Board

How to use CVS when offline?

Last week, I spent about two days just to get different versions of our source code right again ... Oh, yes, we _do_ have a CVS repository at a server somewhere. Problem is, I do most of my work on a notebook offline; I've got access to the CVS repository just when I'm in office, which is about once a week.

Now, I'm wondering whether there is a way to use CVS even in this situation. I'd like to commit my changes at the end of a day (not to have to wait 'til next Monday). 'cvs diff' would also be nice (which rules out this tiny little 'cvsq' shell script).
Of course, I could carry around a local repository with me - but how to synchronize that?

Is there any other way how to do it? Or any other versioning system which provides what I want?

Monday, October 07, 2002

You can have your own local repository, and generate patches to apply to another repository, but it is a pain and CVS isn't really helping you much here.  The likes of Subversion will support better merging to make this process easy, but they don't yet.

You want a distributed version control system.  I haven't tried any of these, but have a look at:


Which all sound like they can do what you want.  How good they are I'd like to hear.

Francis Irving
Monday, October 07, 2002

My take on Bitkeeper:

My background: I do most of my [developing | tinkering | general computer usage] on Windows 2000. I am not strange to Linux / Unix; I tend to have a "second box" with (at least) a copy of some *nix running or in a runable state, for networking testing, and such.

I had used (not extensively, I admit) CVS in the past. It worked. It was useful. You had to set up a remote server. You could not rename / move (other than by calling in a friend who did understand CVS, of course). And up to very recently, for the CVS server Unix was a "must".

Then I heard about Bitkeeper (BK, for short). As a matter of fact, I had been "following" it for a while, as its origins are quite peculiar (BK was "born" as a ways to "shoehorn" a source control system into the linux kernel development process; L. Torvald didn't like CVS, and in any case CVS doesn't lend itself to distributed, "peer" development), so Larry McVoy undertook the task of building a SCS that was up to the task. Thus its evolution throught time has surfaced in the "news" I tend to follow every now and then. Bitkeeper is the (final) result.

As it _has_ been adopted for the development of both 2.4 and 2.5 versions of the kernel, we can guess it's been a success. One of the main features of BK _had_ to be that it had to allow working "the old way" (ie, with patch & diff).

The result? BK _is_ distributed, but works fine locally. It doesn't need a server to run; if you're using it locally it just works. The Windows version requires Cygwin to run, but as I had it already on my machine, that was not a problem.
Renames?: "bk mv old_file new_file"
Deletes?: "bk rm file_to_go"
Can't get much easier than that, can it?
Also, there are GUI (TCL/TK, so if you want them you have ti install it, too) tools for the most common tasks:
<C&P from the help:)>
  bk bkscc - BitKeeper and SCC API
  bk citool - BitKeeper graphical check-in tool
  bk config-gui - configuration for BitKeeper graphical tools
  bk csettool - BitKeeper graphical changeset browser
  bk difftool - BitKeeper Graphical Diff Tool
  bk fmtool - BitKeeper side-by-side merge tool
  bk helptool - graphical front-end to the BitKeeper help system
  bk renametool - graphical tool for finding renames
  bk revtool - BitKeeper graphical history browser

And they say that the integration with Visual Studio and the like is good; I only use the free version, so that's lacking (but it's not a problem for me at the moment ;)

The net result? When I "used" CVS, I tended to use it only for my "real, serious, Macho" projetcs.... or some of them, at least. Now, I have BK set up, so I tend to use it almost everywhere. For instance, I have just got around to tweaking a "mini" personal web site I have hanging around, w/o Source Control. First thing I've done, I've converted ("setup") the BK repository on the dir, so now I can version the files. Time: 1 minute. The difference? Now it's much more likely I'll use versioning ;) And of course I don't fear making "big" changes so much (incidentally, that's one of the main arguments Linus Torvalds has against Version Control systems: he says they make you "careless" ;).

So that's my take on the program. I think it's quite clear that I like it ;)

Of course, I should probably mention that the support is top-notch. I once got bitten by a nasty "won't work and do nasty things" bug, due to the fact I had downloaded a 3.x version (the current one is 2.1, IIRC) from the "test" dir on their server (so it was quite alpha). I sent a mail, and on the following day I got a reply from Larry McVoy explaining the why and how to get out of there ("don't use alpha sw or you'll get bitten";) But even the betas are _very_ reliable. I have been using the July 12th 2.1 version since July 12th ;) and I've had no problems. So much so that I've just downloaded the Oct 3rd version ;)

So, I think that's enough rambling on the issue for now.
Sorry for the longish rant.


PS: Did I mention the tools to import a previous CVS repository and save the history of it? ;)

Javier Jarava
Monday, October 07, 2002

As far as another versioning tool, you might take a look at Code Co-op by Reliable Software.

( )

It is a "serverless" system designed to help developers in different locations collaborate.

Tim Lara
Monday, October 07, 2002

*  Recent Topics

*  Fog Creek Home