This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When you have an unversioned local project and go to make a Kenai project from it, the wizard checks it in to a Subversion repository. You are not even asked whether you rather wanted to use Mercurial (or Git for that matter). BTW the Subversion import is a little odd. The project is created in a subdir of the repo named either according to the Kenai domain or the local project's dirname (not sure which since in my case they were the same), which may be OK but introduces an extra level into the dir tree which is not obviously needed. Also no 'trunk' dir is created, which is unconventional for SVN. Of course you can rename such dirs later if you want to.
Only SVN has been selected intentionally. Git is not offered because NB do not support Git.
Jesse, you are talking about "Share on Kenai" functionality, right? If so - it is intentionally done "for dummies", so it doesn't ask any unnecessary questions. If you want to use mercurial or if you need more control over the directory structure, use Team>Kenai>New Kenai Project. This creates a project on Kenai and a local repository folder where you can then copy any projects/files (for example a "trunk" directory) and check them in (/push).
Mercurial is not offered also for technical reasons. We can checkout SVN into existing local folder, and commit local files into SVN. But we cannot do the same with mercurial. Mercurial needs empty folder to do clone. I'm not sure if we can fix this and still keep it simple.
1. If you do not offer Hg service then the dialog should clearly state that it is going to create a Subversion repository and that users of other SCMs must do a source import manually. 2. "Mercurial needs empty folder to do clone" - yes but you do not need to clone because there is nothing on the server to clone! Just 'hg init', set up an initial .hg/hgrc (paths.default & paths.default-push), add your sources, commit, push.
> yes but you do not need to clone because there is nothing on the server to clone! ... not sure about that... I believe there actually is an empty repository created... you need to clone it first in order to be able to share your sources, otherwise you get the "repos are unrelated" error during push... am I correct?
Yes, an empty repository _is_ created. But hg clone http://wherever/empty/ dir and hg init dir (echo '[paths]'; echo 'default = http://wherever/empty/') > dir/.hg/hgrc have the same effect. "Repositories are unrelated" means that there is a different root changeset in the remote vs. local. Since an empty repo has no root changesets, this will not be shown. (If you actually wanted to create an extra root in the remote repo, you would use --force.)
So it seems it should be technically possible to create a hg repository for a local project too, without moving the project, i.e. get the content of the NB project folder into a new Kenai project's hg repository. The difference would be the NB project dir itself is not in the repository (i.e. there is not the one extra level in the dir tree as Jesse described we do for SVN). Not sure it it is a problem or not. We wanted the project dir be there so it is possible to add more NB projects next to it later. And BTW we should create 'trunk' by default for the SVN repository.
Of course if you import the project as its own Hg repo then you cannot add further NB projects later to the same repo except as subdirectories of the master project or by moving all its sources into a subdir. (A Kenai project can have >1 repo but these would not be versioned together.) Hard to say if that's really a problem or not. It depends entirely on what the user expects to do, which can't really be determined except by asking them. I would probably recommend just assuming that one repo = one NB project as far as the import GUI goes; users who want more complex setups are almost surely going to need to understand how to do their own SCM operations anyway.
we are working on it with ondra
I guess supporting Hg would be a FEATURE but there is a DEFECT that SVN is assumed with no user confirmation.
already fixed by maros