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.

Bug 166866 - Mercurial not offered as project SCM
Summary: Mercurial not offered as project SCM
Alias: None
Product: connecteddeveloper
Classification: Unclassified
Component: Team Framework (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Maros Sandor
Depends on: 165532 169626
  Show dependency tree
Reported: 2009-06-10 16:25 UTC by Jesse Glick
Modified: 2009-11-10 03:34 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-06-10 16:25:20 UTC
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.
Comment 1 Milan Kubec 2009-06-11 07:11:15 UTC
Only SVN has been selected intentionally. Git is not offered because NB do not support Git.
Comment 2 Petr Dvorak 2009-06-11 07:54:32 UTC
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).
Comment 3 Jan Becicka 2009-06-11 11:47:32 UTC
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.

Comment 4 Jesse Glick 2009-06-11 18:38:27 UTC
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.
Comment 5 Petr Dvorak 2009-06-11 20:14:02 UTC
> 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?
Comment 6 Jesse Glick 2009-06-11 21:49:11 UTC
Yes, an empty repository _is_ created. But

  hg clone http://wherever/empty/ dir


  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.)
Comment 7 Tomas Pavek 2009-06-16 18:17:34 UTC
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.
Comment 8 Jesse Glick 2009-06-16 18:30:43 UTC
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.
Comment 9 Jan Becicka 2009-07-17 12:06:00 UTC
we are working on it with ondra
Comment 10 Jesse Glick 2009-07-31 16:14:23 UTC
I guess supporting Hg would be a FEATURE but there is a DEFECT that SVN is assumed with no user confirmation.
Comment 11 Jan Becicka 2009-09-09 09:23:54 UTC
already fixed by maros