Is fan an open source project? I can't find any online way to view the svn/cvs repository. If people start creating patches how are you going to receive them?

Also, what is with the choice of the AFL license? The Apache license is a lot more widely known for that type of license.

Yes, Fan is an open source project via the AFL license. We evaluated several open source source control tools like svn - but all fell pretty short of our expectations. So we chose to use a commercial tool (StarTeam) we had experience with. We are aware that this is an open-issue we need to solve somehow.

We originally chose the AFL due to its more explicit patent defense. However, I agree the Apache 2.0 license is more widely known and accepted, and is essentially the same license. We've discussed switching to Apache, but have yet to make a formal decision.

We choose the AFL license because of a philosophical issue with Apache - you can sue someone developing code licensed as Apache 2.0 for patent infringement and not actually lose your right to use the code - that doesn't seem fair at all. Open source communities have an opportunity to help fight patent abuse - so yes we are using a non-popular license, but at the same time it is basically the same as Apache 2.0 plus the patent defense clause. And it is a pretty liberal license compared to something like the GPL regarding derivative works.

As Andy said we were using CVS and SVN, and in the end fell back to using a commercial product, StarTeam, for our source control. This is an issue we absolutely need to rectify, although I'd like to take the time to find a good solution. I do despise the way CVS and SVN litters my source tree with its own directories (I'll admit to be anal). A good first step might be to sync our trunk with something like SVN to at least provide up-to-date read access.

Although I think your question at a deeper level is how we will manage things - and I'm not exactly sure. To get things started, we're probably going to be extremely conservative with adding new committers. Once the core language and libraries start to settle down, then we can start adding more committers. I'd like to break responsibility down by pods and keep clear lines of ownership. But I want to be up front and honest, I'm not going to let Fan become a kitchen sink language designed by committee. But hopefully we can gather good community consensus on design issues. But I do want to maintain a coherent vision for the language and core libraries, which is why we'll probably start very conservatively.

Here is the Apache part: "If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."

Here is the AFL part: "This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License as of the date You commence an action, including a cross-claim or counterclaim, against Licensor or any licensee alleging that the Original Work infringes a patent. This termination provision shall not apply for an action alleging patent infringement by combinations of the Original Work with other software or hardware."

The difference seems marginal - a loss of patents from the license vs a loss of license. Anyway, not a huge deal.

I think you are right to be cautious about new committers, and your goals for the language. But that has to be balanced with creating a buzz if you want it to be popular. But is being a popular and widely used your goal?

Open source wise, what is missing are the big signs saying here is the repository, here is how you submit bugs, here is how you submit patches. Perhaps you're not ready for that, but its a question you probably need to address soon (and publish on the website).

I agree:

• one of the first steps is get a repository (at least for reads up and running)
• shortly this discussion forum will get enhanced for bug tracking (part of the master plan)
• we need a defined process for patches

Yes we definitely want to be popular long term! Although for the short term I'd be very happy just to get a small, core group involved to help hammer out core language/library.

BTW - does anyone have any recommendations for version control which:

1. doesn't pollute your source tree with its own files
2. has a decent UI available?

If you are aiming to be popular, I would strongly recommend sticking with svn. I know that you dislike the files it generates, but that needs to be balanced with its very wide acceptance, IDE integration, hosting availability (java.net/sourceforge etc) and knowledge-base.

For example, the fact that OpenJDK is on Mercurial has put me off getting more involved.

I'd second that sentiment (sticking with SVN). I found Fan by your participation in Wide Finder 2 and was intrigued by the language. It looks like your implementation depends on a couple of changes not in the latest release... so the first thing I did was to come to your site and look for a repository. :-) Getting that solved is definitely a Good Thing for everyone.

Using something like bazaar might make the patch process easier in the long run... since svn doesn't really have patch support (someone was working on it, but it still hasn't hit trunk). But I honestly don't have much experience with bazaar just yet.

I hate svn litter. Svn also can't track changes across renames on different branches. At least 1.5 tracks branches and merges finally.

I'm willing to learn Mercurial (and NetBeans has built-in support thought I'm still primarily and Eclipse sort), but I understand that many others aren't willing to look at anything other than svn.

And hg does only drop off files at the project root.

In my (limited) experience with hg, it's about 7000x easier to use than svn.

From what I've heard (mainly customer request), git is the next big thing. Although I don't like the approach it takes to version control, there's no denying it's fast and pretty easy to use. But...

As difficult as it is to use, Subversion is your probably the best bet for the long-term. The trick is finding an interface you can actually live with.

On Windows, a lot of people like TortoiseSVN because it integrates with the Windows Explorer interface. It works especially well in combination with a text editor like e, which uses a native explorer window to show you the files comprising a project.

UNA also has nice support for Subversion. There is no svn litter -- just your files. However, you need to do everything through the UNA interface (creating files, adding them, renaming them -- any operation done inside UNA will be reflected on the next commit). Note that there's no way to do Subversion command-line operations (well, there is a way but it's tricky and not supported).

It looks like your implementation depends on a couple of changes not in the latest release...

Even with the latest code, we actually haven't solved the mutable messaging.

I'm willing to learn Mercurial (and NetBeans has built-in support thought I'm still primarily and Eclipse sort), but I understand that many others aren't willing to look at anything other than svn.

I'm pretty sure I want to use a distributed version control system. I think it is more suited to the way Andy and I work. Plus I'd like to use a pull model for community development. Individuals working on pods can maintain their own repository, and I will pull into the master repository. For a project like Fan which will likely have a fairly big library (I hope), this seems to make sense.

For distributed version control the two main contenders seem to be git and mercurial. I haven't used git, but my understanding is that it isn't Window's friendly and Window's happens to be an important constituency for Fan. So the leading candidate is mercurial. I also like that mercurial is being used for OpenJDK.

Many people have said they would prefer SVN, although I don't think it is the best tool for the job. Although sounds like both git and mercurial will be able to synchronize to a SVN repository sometime soon (hg seems more behind than git on that).

I haven't used mercurial much yet, so I want to take some time to learn it well. But the plan is to get a public repository up this summer.

Even with the latest code, we actually haven't solved the mutable messaging.

Ah, didn't even see that one (and I looked at the thread!).

I'm pretty sure I want to use a distributed version control system. I think it is more suited to the way Andy and I work. Plus I'd like to use a pull model for community development. Individuals working on pods can maintain their own repository, and I will pull into the master repository. For a project like Fan which will likely have a fairly big library (I hope), this seems to make sense.

Sounds like you're getting this all figured out... awesome!

For distributed version control the two main contenders seem to be git and mercurial. I haven't used git, but my understanding is that it isn't Window's friendly and Window's happens to be an important constituency for Fan. So the leading candidate is mercurial. I also like that mercurial is being used for OpenJDK.

Personally, I tend to like git over mercurial, but git's windows support stinks (it doesn't help that I despise cygwin). If you want Windows support to be a first class citizen, I'd stay away from git for now.

Many people have said they would prefer SVN, although I don't think it is the best tool for the job. Although sounds like both git and mercurial will be able to synchronize to a SVN repository sometime soon (hg seems more behind than git on that).

My only reason for suggesting svn it because it has a lower barrier to entry since it's so prevalent. That's great because it's less for a developer to learn when joining your project. However, I'm not an svn zealot, and I think one of the distributed tools will either knock it off the top, or folks will just become familiar with several tools over time (that's certainly been the case for me). As for svn integration, git-svn works great. The last time I tried hg's svn integration--and it's been a while now, it was still very much in it's infancy. I wouldn't be surprised if that's changed by now.

I haven't used mercurial much yet, so I want to take some time to learn it well. But the plan is to get a public repository up this summer.

Awesome. Having this stuff in place definitely helps to have a community. :-) One other suggestion I'd make it to use mailing lists over forums... it's a lot easier to keep track of what is going on that way.

One other suggestion I'd make it to use mailing lists over forums... it's a lot easier to keep track of what is going on that way.

Both email and atom are supported: http://www.fandev.org/sidewalk/topic/232

Andy: you should include the email config on the register page too.

Thank you!

Take a look at Bazaar also, has much better cross platform support because it is python based.

I don't like mercurial because it does not track folder changes, like file rename or file move.

I agree with wirianto. I use Bazaar on a daily basis, in conjonction with eclipse (the plug-in is still in development but quite usable) both for personal and professional work, and it works really like a breeze.

Concerning git, a Windows port happens to be seeing some good maintenance these days.

I don't mind evaluating bazaar too. My main issue with bazaar as it doesn't seem to have the momentum of git or hg. Although there seem to be a couple big projects like MySql using it.

The rename/move issue is something I really wanted to play around with on hg because what I've read concerns me. I like to rename/move a lot. Can someone explain the issues hg has with this and how git and bazaar do it better?

Well, as far as I know, Bazaar is the only DVCS that also keeps history of directory, not only files.

IMHO git may be well suitable.

We use git heavily for about a year to manage both our production and experimental code. I can just say that it is very well designed (its data format hasn't changed from the very beginning) and you can do unbeliavable things while integrating various sources and patches once you mastered it. Its development also shows very fast progress.

I wouldn't change it for svn/cvs even if I'd be given a golden pig!

Git Java reimplementation is now pushed forward by the summer code so I hope it will turn into to something usable soon...

we are in the process of moving to hg