After staying up on Thursday night until at least 4:30am (times are hazy after that) I'd planned to get an early night last night. Until Uncle Steve said there was a party on our floor after the keysigning. This never quite happened (people gathered outside instead), but I still ended up getting to bed at around 7am. It's probably put me in the right frame of mind to continue looking at mjg59's x86emu issues though.
So I had this conversation with Hanna last night, where I mentioned about the fact I find prolonged online conversation usually quite hard work (say in a debian-devel thread, rather than personal mail to a friend). And she replied by saying that based on her original email/irc conversations involving me she'd thought I was quite bland, but after actually meeting me she'd decided I actually was interesting enough to talk to. Which is interesting, because I like to think I can be entertaining enough to talk to (don't we all). And I got to thinking that perhaps the fact I never seem to able to blog is related. So, I'm going to try harder to do this, in the hope that it will also persuade me to participate more in mailing list discussions where I feel I can add something.
As I write this I'm sitting in tiny Air Wales twin propellered plane, going from Norwich to Dublin. Possibly the smallest plane I've ever been in - only 4 seats wide. Much more civilised than having to travel to Stansted to fly back to my parents' though.
Went to see TFM in Oxford over the weekend; it was good to see him again - we're very bad about keeping in touch. Bizarrely ended up playing Doom the Boardgame (and staying up until 4am doing so). This has caused me to install prboom again with the aim of completing Doom 2 - when it came out my machine wasn't fast enough to cope after the 5th level or so.
Out last night in Cambridge; Monday pizza followed by the Live and Let Live with Debian folk. Finally gave Steve back his pliers and a WMA11B - told him he had to help me convince Vince to get mainline kernel support for it. It's the only device lacking IPv6 support on my home network as present. Ended up walking back to the car with tbm and discussing his PhD; he seems to be focussing on release management now and I'll be interested to know what conclusions he comes up with. Oh, and Nattie decided my shoes needed to smell of apple and melon and spilt her drink over them.
So, let's try this blogging lark. I'll at least start writing stuff and if in time I think I've written anything interesting then I'll look at sticking it up.
Today I got acused of regarding Debian's founding principles with contempt (msgid: <20041216232946.GF13139@zewt.org>). mjg59 stepped in to protect my honour and said "Given all he's done for Debian at various points", which gives me a warm fuzzy feeling, but makes me wonder what good I have done Debian. I'm a keen supporter of it and try to recommend it whenever I can; I admin a buttload of machines (both personal and business) that use it, but how does that really help the project? I've been finding our inability to release quite depressing, but I can't figure out what I should be doing to help us forward. It's not like any of my packages are critical or holding things up. I don't have the appropriate knowledge to help out on the infrastructure holdups. Or maybe this is the wrong attitude? Maybe I should be diving headfirst into the archive code and seeing if I can come with some neat stuff that helps us? I don't know. There just aren't enough hours in the day really.
Why PVCS sucks. I originally wrote this for work where I had to use PVCS, and I think it helped in my convincing them to try something else (which happened to be CVS, which isn’t perfect either, but is better and free).
- You can’t delete files.
- If a file is checked into the repository and then at a later stage is no
longer required then the file must either be deleted at all points in the
tree or will remain there forever. There is no way to say a file only exists
up to a certain point in time and at that point disappears.
Workaround: Define a LATEST tag and make this float with the tip of each file. Then to delete a file remove the LATEST tag from it. Requires all checkouts to be done from LATEST rather than just pulling normally.
- Checkouts are automatically locked.
- When a file is checked out it is locked. This means that it’s not possible
for a developer to check out a file, work on it and check it back in while
another developer also has the file checked out. This could, for example,
happen if someone is working on a new feature release and has checked out all
the files involved. A bug is discovered in the current release and someone
else checks out the code, fixes the bug and then finds they can’t check the
fixes back in.
Workaround: It’s possible to break locks so that the files could be checked in, but this requires the cooperation of a PVCS admin and also leads to the problem that the feature release checkout doesn’t have the bug fixes in it.
- There’s no way to update a checked out tree.
- If you check out a tree and someone else does some work on it and checks
something back in then there’s no way to pull the new changes into your
checked out tree. Either you pull the new file, removing any changes you’ve
made locally, or you ignore the new file and end up overwriting any changes
when you check your version back in.
Workaround: This normally wouldn’t come up, given that checking out a file locks it. However that leads to the problems above.
- It’s not easy to find changes in a local tree.
- If you check out a tree and do some development on it and then want to
review your changes against the repository you can’t, easily. This is
something revision control should do for you - it should make it really easy
to check what changes you’ve made to allow quick sanity checking and help
narrow down where problems are likely to have been introduced.
Workaround: It should be possible to do this by either checking out the whole tree again and doing a diff or using the PVCS command line tools to individually compare each file with its archive file. Neither is pretty though.
- There’s no local state.
- When you check out a PVCS tree there’s no local state pulled with it. There’s no easy way to tell what version you’ve actually pulled nor to come back to a tree after a period of time and be sure exactly what you’ve got.
- It’s not actually platform independent
- The PVCS repository appears to be tightly linked to where ever it was originally created. It’s not easy to move this and if created on a Windows UNC style share then it’s non portable to other platforms. In fact it’s not easy to access a PVCS repository from a variety of platforms, leading to the kludgy solution of having to check code out to an NT machine and then from there to the development environment.
- You can’t rename a file
- If you want to rename a file in a PVCS repository then it can only be done by removing the file from the repository, running the VCS cli tool on it and readding it. This is what the Merrant support site suggests and it renames the file at all points in time rather than just from the current point on the branch/mainline.
- No changesets
- When a file is checked in it exists on its own; it’s not possible to find all
the files that were updated as part of a particular checkin (say a bugfix
that touches several files; it’s not easy to pull out just the changes that
were part of that bugfix).
Workaround: It’s possible to work around this a bit if the same description is used for each file that’s checked in at the same time.
- Bad user interface
- There are several issues with the PVCS user interface. It’s extremely slow
for starters. Also checking in files can be non intuitive - it’s required to
explicitly state that unchanged files shouldn’t be checked in again, for
Workaround: None really except more use of the product to become familiar with it.
subscribe via RSS