New ideas and suggestions

1. Web application to manage users and repos using hgwebdir and ssh authentication

It would be very useful having an app that would:

• allow a site admin to tweak the hgwebdir configuration
• let users create an account providing a name, an email account, and a public ssh key (or an SSL key if using https)
• after admin approval, add the relevant bits to the ssh configuration file for registered users
• allow the admin to select which repos can be accessed by each user or group of users by checking and unchecking boxes in a list of repos
• allow to create new branches from an existing one and let the admin choose which repos can be branched for each user or group of users (a branch should be a clone from the master repo of the project, or any other specified repo)
• allow to create new (empty) repos

  Please be sure to create a separate webapp for this so hgweb/hgwebdir would stay KISS. Some users (maybe most) will not want to use the web interface for managing repos... -- Radek Podgorny

  The web app could be a plugin for Trac (http://trac.edgewall.org).

2. Add stats support to hgweb and hgwebdir

Hg web servers could add a page providing some useful stats for the existing repos like what [http://statcvs.sourceforge.net/statcvs-stats/ StatCVS] does.

3. Application to create, validate and initialize configuration files

It would be very useful having an app that would:

• creation of new hgrc files
• be used for the first-time initialization of hgrc files
• validate existing hgrc files
• tweak existing hgrc files to add/change options and activate/deactivate avaliable extensions

It could have:

• different standard modes to do partial configuration, such as a first-time minimal configuration, shared repo with allow-push configuration...

It should at least have a text interface (a simple one to do the first time configuration, as asking for username, email, editor...)

4. Greater flexibility for merge/export

Experience from several other systems suggests that the current approach to handling BinaryFiles is not adequate. mpm is absolutely right that the notion of a binary file is intrinsically confused. Unfortunately, that doesn't mean that we can avoid it. This needs some discussion, so I'm attempting to add a page for that: NewIdeas/FileTypes

5. User friendly off-line synch of distributed repos using "Bundle Digest"

see [http://www.selenic.com/mercurial/bts/issue392]

6. Combine the advantages of named branches and clone branches

Named branches ("hg branch" command) have the following advantages:

• easier to use: you only need to specify a name instead of a complete URL
• simpler branch creation: no clone(s) on the server needed (and thus no need for shell access or special scripts)
• easier branch hosting (the server does it all for you)
• less transfer overhead (when pulling a branch and when pushing a merged repo)
• all developers can follow all active branches very easily (only one pull for all branches)
• branch switching is more space efficient than having multiple separate clones of each branch

Clones have the following advantage:

• simple and effective for working on small, independent changes in separate, local repos
• small download
• easy to learn concept for local changes

The ideal solution would unify clones and named branches and combine the advantages of both systems.

One possibility (but probably not very good) would be to have a shared top-level folder that stores all changesets of the reference repo. This top-level folder then contains subfolders for each checked-out branch and these subfolders only store the additional changesets for the top-level folder and the actual source files of the checked-out revision. For example:

• /repos/hg - top-level folder for hg
• /repos/hg/.hgshared - shared folder with all changesets of the reference repo and global settings (e.g. username, default URL, etc.)
• /repos/hg/main - a working directory of a checked-out branch
• /repos/hg/main/.hg - the branch settings and branch changesets which don't exist in the reference repo
• /repos/hg/newfeature - another working directory
• ...

7. Provide a simple function/tool for creating changelogs

It would be nice to have a tool that assists you in changelog creation. SVN can export the history as XML and svn2cl can convert that into a nice-looking changelog. We should have something similar (maybe without the extra XML conversion step).

You can use hg log --style=changelog for this, and XML is not the solution to everything. -- ThomasArendsenHein DateTime(2006-12-07T09:43:51Z)

8. Provide an extension to push/pull and view remote repos using just rsync/ftp

I would allow to publish repos without the need to have python or hg installed on the server. Even for a read-only use it could be nice to have.

Also, it would be really wonderful being able to view the remote repo even if that involves pulling the remote repo using the rsync/ftp extension and locally launching the smart server to view it on a browser.

With these, publishing a repo could be just a matter of copying a dir, which is a good win for people that don't have too much control over the servers they use (yes, there are servers without python 2.3 on them and where you don't have shell access and are still useful to share that info).

This extension, along with mail bundles to send patches to maintainers would make a cheap and dirty way to have a DVCS platform.

9. Extend push/pull to include progressbar

This would make me very happy. I use hg to manage my personal photo collection (several gigs) and transfers take really long. Some progress indication would be nice...

It doesn't have to be a percentage gauge, only a "sending diff for file 456 of 78678" would be fine, too...

10. Suggestions for handling commit text

(This is already covered in TipsAndTricks under "Adding a commit message template")

• A capability to include a specific template for the commit text when using an editor would be useful for those repositories (like ours) which need to have users include an integration approval number and/or a bug id. Whilst we can ask the users to add this, it is easier if they could be simply presented with a template when calling commit.
• It would very useful to be able to call an external hook to validate commit text and possibly change the text itself. An example of this we have today with CVS is that the user can use "auto" as the integration approval number. When this is detected during the CVS commit, a script contacts a web service to get an approval number and replaces "auto" with this number in the commit text. Validation would also be useful for filtering of commit text (eg for bad words).
• An extension to the above might be to have some way of auto-validating some text within commit text. It might be difficult to find the correct metaphor to express such fields and then implement the validator for it, but it could start simple.

I already have an idea for the changes for the second item. If my limited understanding of Python is correct, it would simply be necessary to add a call to the hook as: {{{newtext = self.hook("committextverify", text, parent1=xp1, parent2=xp2); if newtext is None:

• return None;

text = newtext; }}}

11. Add shelve/unshelve extension

A convenient feature in bzr is that provided by shelve/unshelve, so changes that haven't been commited can be selected, discarded or put aside interactively using the shelve command and with a diff hunk granularity. That way, you can backup and put aside some of the hunks, commit the rest, and later restore the shelved hunks using the unshelve command.

To see the how the original shelve plugin for bzr works have a look to [http://bazaar-vcs.org/BzrShelveExample its webpage].