Here I am migrating some stuff from one system (StarTeam) to another. So after conversion (it creates a dump file) I load the dump file. I then purge unnecessary files and move files around. Then I create a dump of that.

I know I can use svndumpfilter (but it's crap), but there is no permanent deletion option (so all the files that shouldn't be there are lying around consuming space and wasting time in loading). When I watch the process of 'svnadmin load' you can see why it's painfully slow - it creates your repository as it was then applies all the changes afterwards (like my moving of folders/files and deletion of files).

I like SVN, but svn load/dump and purging is dreadful.

I assume it wouldn't be that hard to parse the dump file and just delete crap you're not interested in.

Which is pretty much what svndumpfilter does.

Subversion does suck, though I think this is the least of its problems. If you can, I suggest migrating to Mercurial or Git. At the very least, acquaint yourself with them so that you can recommend them to your company.

** EDIT **

Neat. Git actually has the ability to do this relatively easily: http://help.github.com/removing-sensitive-data/

I'll be trying it out in a minute so I'll let you know how efficient it is.

** EDIT **

I actually had to edit a password out of a file so I couldn't just delete it, but Git did it just fine. My project is quite small so it was fast, but I'm guessing it would be quite slow on a large repository (understandably). Apparently you can speed it up by specifying tmpfs as the device to work on.

Anyway, my command line was basically this:

git filter-branch --tree-filter \
        'find -name SourceFile.java -execdir \
        sed -i s/sensitive\ string/placeholder\ string/' master

git log -Ssensitive\ string
[Should be no output if it worked happily]

[Make sure the repository looks happy]

git push --force origin master

Unfortunately, apparently the sensitive information still exists in the repository, but we've basically hidden it. If somebody has the SHA1 hash for the now hidden branch then I think they can still recover the data. You'd have to create a whole new repository to completely get rid of it. This is fortunately pretty easy since you already have a complete clone of the repository (though I'm not sure whether or not pushing into the new repository will again push that sensitive information). I used this to fix a project on GitHub that had a relatively worthless password in the source code, but a password nonetheless:

http://github.com/bamccaig/bambot/blob/154a389aa0002e18e7684625663fb68a91552bb6/src/org/castopulence/bambot/BamBot.java

Note line 40.

Your quit function is overly verbose and unnecessary. You can just quit with your quit message.

It doesn't seem to actually work anyway. At least, when I've tried it in the past it would just quit without giving a reason. If you're referring to parting from each channel before quitting then I suspect you are correct. I was more or less experimenting when I wrote the existing code. I haven't actually begun writing anything remotely useful yet.

Yeah, I've noticed that the quit message randomly doesn't go through on Freenode. Try testing on a network that doesn't use buggy IRC servers.

Anyway, it doesn't really matter if the quit message goes through or not IMO, especially if you're writing a bot.

We use CVS at the j0rb and I think it's pretty useful. I've had to make branches of projects before and merge them up after making drastic changes with little problems (.NET). I have to say though that checking out and committing changes is a little slow, but I'm getting paid for it so why complain .

You just have to try out Subversion and you'll quickly see that CVS doesn't work very well. Then try out Mercurial or Git and you'll quickly see that Subversion doesn't work very well either.

Git didn't have a good GUI when I tried it (a year ago). TortoiseSVN is amazing

There is a TortoiseGit now, but I think it's still somewhat immature and installing it isn't as simple as with the other TortoiseSCMs (you have to manually install msysgit first, which in itself isn't completely non-trivial). That's only relevant to Windows though. Linux and presumably other unices have had gitk for a long time, I think.

Not that it matters. The GUI wrappers all suck compared to the command line interface. GUIs are fundamentally flawed when it comes to non-graphical work because they require 10x longer to design and develop and 50x more work to use for non-trivial things (and they don't interface with one another easily). GUIs are nice for graphical data, like a branching graph, for example, or graphic design. Get used to using the command line. Even in Windows it's a lot faster and cleaner for 99.99999% of things (especially when you install Cygwin or MSYS to supplement it).

I think KDE has a git plugin now. So you can see git status from Dolphin, the file dialogs, or konqueror.

...which also sucks.

Git is an excellent system, but goddamn can you tell it was written by coders for coders. I don't know why you'd decide to improve the mechanical side of version control without even keeping the same level of usability.

Also, for my OS X brethren, GitX is an okay GUI for Git. I still use the command line most of the time though.

I use git.

I tried it a year ago, and it was too buggy to use.

Exactly, that's the problem.

I value having a GUI interface to whatever SCM I use. Therefore, Git, from my point of view, sucks, because it doesn't have a good GUI. This isn't about what is the most effective way to use a tool; I am simply more comfortable using a GUI.

Also, updating a Git repo from one machine to the rest of my machines was too difficult. I tried out Git over a year ago, so my memory is vague, but I remember spending a few hours trying to set up every machine just right, and still couldn't get it to work fluidly. I eventually just gave up and setup a project on Github, but then that kind of defeated one of the key features I liked about Git (being server-less).

But if you ever get to try out Perforce, you will realize that even CVS is great.

I tried perforce a while ago and it was ok, but after using tortoiseSVN I prefer the non-thick client approach, either the explorer plugin like tortoise or direct IDE integration. I don't see why I should have to use another program just to manage files.

Actually it's incredibly easy from Linux to Linux. You probably won't even need to worry about setting up daemons because Git can work directly over SSH. For example, if you have a repository at /home/user1/src/project1 then you could use the URI user1@host1:src/project1.

git remote add my_remote user1@host1:src/project1
git push my_remote master

And just like that, it will be updated with changes to branch master from your local copy of that repository. When you clone, you typically get a remote named origin already set up for you that points to the cloned repository.

It seems getting a daemon running with the git protocol is a little bit more work. There is git-daemon for this, but it doesn't support authentication so you'll probably only want to use it read-only (the default). I haven't quite figured out the daemon aspect of Git yet.

Which is awesome. SSH in Linux seems to come in handy on countless occasions. However, some of my machines run Windows.

To be clear, I want to use Git. From what I have read about it, it has features I would enjoy. I just seems to have its head up its butt and refuses to support anything other than Linux with a CLI. So, here I am, stuck with SVN.

Unfortunately, you're just wrong.

Basically, Git supports way more protocols than Subversion does. It was developed by UNIX programmers for UNIX programmers. I really don't think Linus Torvalds could care less about Windows (for good reason). In the beginning, the only way one could use Git (and therefore begin to care about it) was if they were a UNIX-like user.

Since some of us have to work with Windows anyway (some of us you might even choose to), other people are taking on the challenge of porting Git to Windows. They've done a good job and it is mostly usable in Windows now with msysgit. However, it just hasn't reached a point yet where anybody has put a simple Windows installer together, let alone a simple server bundle for Windows. It will happen, but you have to realize that it will take some time.

Honestly, if the code you're working on is intended to be released as open source then you're best off just using a free service, like GitHub. If proprietary, you always have the option to pay one of those services to host a private repository for you too. Or you can just run a Linux box somewhere and get a "central" repository working on it to use as a go-between. If you try hard enough, you can probably just get a service running in Windows to work as well. It seems you can use Apache and WebDAV if you're inclined to do so.

With a bit of bastardization, you could even host a Subversion repository and then use git-svn to communicate with it (though I wouldn't call that a full-fledged Git experience).

There's always mercurial; it's slightly less feature-laden than git, and maybe (although I haven't noticed yet) a bit slower, but while git is an amalgamation of C programs and shell scripts, and thus harder to port to non-unix-like platforms, mercurial is written in python, and the windows version is pretty much on par with the various *nix ones. There's a really nice painless introduction written by the Joel from joelonsoftware, which should help avoid a lot of confusion, especially for those coming from a central-repo SCM system.

A CLI program is about as thin as it gets. An explorer extension is in fact just another program (or a whole bunch of them), and so is an IDE plugin; you just access them from within another program. Most IDE plugins I have worked with are even worse than Tortoise{insert SCM}. There's another reason people like CLI interfaces: They're scriptable. A distributed SCM also gives you a sophisticated incremental backup mechanism: Just write a little script that pushes all your local repositories to a backup location, put it in a cronjob, and that's it.

Oh, and before bashing any SCM, just try to remember what it's like when you have to work without one. You don't want to go there - everyone working on the same network share? bi-hourly zipped backups? keep track of versions in Excel? mailing around individual source files and puzzling them together in nerve-wrecking all-nighters? No thank you. I'd even take CVS over that.

I have it on good authority^[1] that tarballs and patches are actually more sophisticated than CVS. They certainly sound more friendly to me. Now, if it was a choice between working on the same network share, tracking changes with Excel, or using CVS then I would probably give in and use CVS...

You could probably write a VCS in Excel though. People have wasted countless hours writing all kinds of crap with that thing.

Aww, how cute. Little bam bam wants to be just like linus when he grows up. He even believes that tarballs and patches are better than CVS.

You use Visual SourceSafe, I suppose?

[EDIT]

I found this googling:

"SourceSafe was a perfectly adequate source control system in the late 90's. Unfortunately, SourceSafe was never updated architecturally to reflect modern source control practices. Even the latest version, SourceSafe 2005, absolutely reeks of 1999. And, to be fair, some of the same criticisms apply to CVS. CVS is no longer a modern source control system, either; it doesn't even support the concept of atomic checkins"

http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html

After working with a few years with VSS & CVS, SVN was a welcome blessing, even though it is not perfect. I've been looking into mercurial myself, and also tried using Git but installing TortoiseGit was a PITA; on the other hand, TortoiseHg was much faster to install, plus it seems to have better IDE integration (I consider that a must for VCSs) (I tried in Visual Studio but not in Eclipse yet - seems that there is a Git plugin in development called EGit, it may be worth a try).

unfuddle.com gives away free private accounts (comes with git) limited to 2 users. Unfuddle has very nice project management stuff as well.

I'd rather have my co-workers and me work with a command-line-only subversion than the f*cked-up mess that is AnkhSVN. Anything that goes beyond "This is my project, I want all the files in it to be versioned, and I'll never move them" is often too much for it to handle appropriately.

Could be, a few years ago we tried AnkhSVN on a project and it was very buggy and not well integrated into VS, and found myself using TortoiseSVN for most of the tasks. Have you tried any recent version of AnkhSVN? looking at their website suggests that they have improved the integration, but it is not clear if they solve the bugs. Subversive works well on Eclipse though!