If you read this blog regularly, you know that I spend a reasonable amount of my spare time contributing to the FlexWiki project. You also know that although I think it's a cool project, I hate the fact that the source code is hosted at GotDotNet. Well, we're looking at doing something about that, but it's going to take a little longer than we hoped. So in the meantime, I've relocated all the pieces that I have control over to a SourceForge workspace called fwcontrib. This includes:
- FlexWikiPad. A tool for writing wikis that live on your hard drive and don't require any web access. Great for organizing information and taking notes - sort of like OneNote, but uses FlexWiki syntax. I use it every single day.
- FwSync. A tool for automatically synchronizing a FlexWiki web site with a set of wiki files on your local hard drive. The synergy between this and FlexWikiPad is obvious, but even without FlexWikiPad this is handy if you want to do a bunch of wiki work offline.
- FwDocGen. A tool for generating a pile of wiki pages based on the XML comment files the C# compiler emits. Because FlexWiki has the cool ability to email you when pages on the wiki change, we're using this at one of my clients to set up a build process that maintain a wiki of code documentation that will notify you when something changes. This one still needs some work, but even as-is it's still fairly customizable.
- FlexWikiEmacsMode. A simple emacs major mode for editing FlexWiki files. Can be used in conjunction with FwSync to work offline.
- WikidPad2FlexWiki. A simple tool for converting the XML export of the very nice WikidPad tool to FlexWiki syntax.
Not all of these tools have been packaged for release yet, but they will be soon, and the source code is all there.
I'm going to be working on the project to make all this stuff better over the coming months. If you have any feedback for me, be sure to log a bug or a feature request!
Have you considered using SourceGear's public Vault server? DotText is currently using it and a few other projects as well.
ReplyDeletehttp://dottextwiki.scottwater.com/default.aspx/Dottext.SourceCode
I am presuming that you just have to ask Eric Sink nicely and he will setup a repository!
I looked at SourceGear's public Vault, but I have a few problems with it:
ReplyDelete1) It looks like it's running on exactly one machine. Not exactly robust or scalable.
2) It's just source control. I like that SourceForge has other project services, particularly the file release system.
3) SourceGear uses the same broken-ass lock-on-checkout model that VSS does, right? I could be wrong on that one. But at any rate, I really like CVS + Tortoise.
Thanks for the suggestion, though!
Re: Vault and check-out locking
ReplyDeleteVault allows the client to be configured in two main ways: using VSS style check-out/edit/check-in and CVS-style edit/merge/check-in.
Actually, that's a simplification - you can configure the separate options 'Require Check-out Before Check-in', 'Make Writable' and 'Always Request Exclusive Locks' separately. Most people just press the big buttons for VSS- or CVS-style, though.
The main issue with using the VaultPub server is that anyone wishing to contribute has to get a username and password from SourceGear.
Cool. Good to know it allows the more sane option. I'll still stick with SourceForge for the other two reasons, though.
ReplyDelete"I hate the fact that the source code is hosted at GotDotNet."
ReplyDeleteThis may be an overkill question for a blog comment, but feel free to post a separate blog entry about this, if you want;
Why does everybody hate GotDotNet - I've almost been convinced to place a project there, and I couldn't really come up with any good reasons why not. I keep hearing that people don't like it, but not really why.
We already have a dedicated CVS server, but none of the other services...
Thanks for any insights.
Search my blog for GotDotNet, and you'll see my reasons in more detail. Briefly, I have found the following problems:
ReplyDelete1) It totally lacks decent automatability, which is crucial for doing real builds. What tools do exist are unstable.
2) It loses files.
3) It's really slow.
4) It uses the lame lock-on-checkout model of course control, rather than my preferred merge-on-commit model.