Squawks of the Parrot

Subversion won't do that now, but people have been talking about cross repository merging features for post-1.0, which would let you use a local repository for your development, then merge your changes back into the real repository later. This is all blue-sky kind of stuff at this point though, we're just trying to get it out the door at this point.

darcs claims to do this, I think.

http://abridgegame.org/darcs/

Of course, it's written in haskell, and you have to get ghc compiled, which is no small feat. ;-)

Open CM - http://www.opencm.org/ supported offline revisions at one point in time. I haven't looked recently though. It's being written for use on the EROS secure OS project because they needed to be able to verify the security of their revision history. It's nice because it can track changes across file renames etc.

If it's on the list of "It'd be nice" for subversion, that's great. There's a limit to how much I'll whine or demand this sort of thing, since it's not like I'm contributing time or cash to the project. I'm happy to have any source control system at all that I don't have to pay for. (Well, OK, I'll whine about things that were broken by design in CVS, but only a little... :)

As for the rest, the other issue I have to deal with in source control is client portability, which kinda rules out a haskell solution, unless anyone has a VMS haskell implementation. (Though for platforms not doing active weird development, all I really need in a client is basic checkin and checkout abilities--something written in perl would be just fine there)

Ah, well, enough blue-sky and grumble, and off to actually do something.

BitKeeper would do what you are asking for. My impression is that it's the one thing BK is really good at.

Subversion supports some offline functions by keeping an extra copy of the last checked out version (so basicly you get "revert" and diff and such things).

Handling changesets is being talked about but is not planned for until post-1.0.

- ask

well, unfortunately, if you're looking for a version control system that will run on VMS, i don't see Subversion doing it any time soon... someone will have to port APR to VMS first, and even then there will be the nightmarish job of making Subversion work with VMS style path names. it may happen someday, but i don't know of anyone with the motivation to make it work soon.

Luckily the APR is already on VMS, or will be soon, courtesy of DEC^WCompaq^WHP's port of Apache, so that's not a problem. The C RTL on VMS is very Unix compliant at this point, so as long as you're not doing things that involve fork it ought to work with minimal trouble.

Granted, it won't be a port with deep and meaningful knowledge of VMS' filesystem, file structures, and interesting features so stuff like ACLs or FORTRAN-format files won't check in or out, but for source and structureless binary files, it ought to work well enough. Which, honestly, is all I really need--if I can check out and check in, the rest is gravy. Well, unless someone comes out with another VMS laptop, but until then I'm more interested in funky Subversion stuff being doable on my OS X laptop.

i was wondering if/when DEC^WCompaq^WHP would be getting around to porting apache2 (and thus APR). i imagine it has to happen at some point, i just hope that when they do they will be contributing the changes back to APR directly (as is currently done with the Netware port). if they do, i'll likely take a shot at getting Subversion up and running on VMS, as i currently work for a company that uses a lot of VMS machines, and it would be nice to at least have the option of using Subversion on that platform (we currently use Perforce, since it runs on VMS and pretty much all other version control systems that don't suck don't).

OpenVMS Engineering can be a bit slow about getting their changes checked back in to open source projects. I don't know the status of their interaction with the Apache community, but they do distribute their own source kit here:

http://h71000.www7.hp.com/openvms/products/ips/apache/apache_source.html

Dan, as far as a VMS laptop, I think the simh VAX emulator does run under OS X, but I haven't tried it.

I don't want a VAX emulator on my laptop--I want an Alpha chip in it. :) Or, barring that, an Itanium, once VMS engineering gets things finished. I hear they're rather far along, which is nice. (Odd that the only reason that I care at all if the Itanium ever sees the light of day is because I want a VMS laptop. Go figure :)

I hadn't realized that not everything had gone from VMS engineering back to the original projects yet--I always assume that folks running VMS boxen will be snagging their stuff from the good folks in VMS engineering.

unfortunately, the apache source kit that openvms engineering is distributing is based upon apache 1.3.x, which is totally useless with regard to Subversion.

what we really need is something based on apache 2.x, or at least a port of APR. that's really all that's needed from my point of view, as i know i won't be able to get the Subversion server up and running on VMS anyway, since it would require berkeley db, and i don't think that works on VMS. an APR port would let us get a client that would connect to a repository running on unix or windows, which would be enough for many people.

A CVS command that says "mark the current state as a snapshot/new base" is "cp -rp". It's not space efficient, but disk is cheap. You make same changes, copy the directory, make more changes in the copy, etc. Then you just update/checkin in the order you made directories.

While the cp trick is quite useful, alas disk isn't cheap. I do wish it was. This laptop has a fixed-sized drive which isn't going to be getting bigger, well, ever. I'd love to say that I usually run with 1G+ free, but that's not often the case (though I can usually pitch some MP3s since those are backed up on the server). At the moment, a full build of parrot takes, with the scrap files, about 135M. That's rather a lot, especially since for what I need trees for, I usually need two or three separate copies off the base tree, then all the tree merges before building. (Otherwise patches from different people don't get credited or merged properly)

Still, for one or two pending changes it's not a bad option. Just not a viable one for what I really need.