New ideas and suggestions

1. Being able to manage a collection of repositories via the web

It would be handy for both departmental servers and public ones There is a rough plan for it in HostingDesign, but needs someone working on it.

2. Clone from a Bundle

hg clone http://example.org/project.hg

Should be equivalent to:

mkdir project
cd project
hg init
hg unbundle -u http://example.org/project.hg
cd ..

Why? Because it's much, much quicker than static-http and therefore the best way to share a project if you can't use hgweb.cgi (if, for example, your server is version mismatching with it).

3. Fallback to static-http if http not available

At the moment when you try to use http and a repo is only available under static-http, it won't bother to even look to see if static-http is available, instead just giving a 404 Not Found error message. It'd be a lot more helpful if it checked for static-http, even if it then prompted the user before continuing–"this might take a while; proceed? [y/n]".

4. 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).

5. Add stats support to hgweb and hgwebdir

Hg web servers could add a page providing some useful stats for the existing repos like what StatCVS does.

+ This would have to be a seperate module that will have to be scheduled on a daily basis.

It could actually be done as multiple module/hooks:

• new page(s) for displaying various graphs and such
• .hg/stats dir

stats dir contains files with filename = graph key and special format:

# graph name
# graphtype (special identifier for the type of graph)
# description (may contain html tags, may span multiple
# lines, each starts with #
graphdata in format specified for graphtype 
  (perhaps csv, perhaps some sort of json-like python structure, etc)
#-- 
(some sort of delimiter; the stats code inside hgweb wouldn't read 
  past here, but extensions, hooks and cronjobs can)
here you can store private data (so for example one graph could be 
  average-commits-per-push per developer and in this part you could 
  store intermediary data so that you don't have to recalculate every 
  time)

As long as a file exists, there would be something visible for it in the website; these files can be created any number of ways:

• extensions
• hooks (changegroup sounds like an interesting place)
• cronjobs
• webservices (part of a CI process perhaps?)

6. Application to create, validate and initialize configuration files

It would be very useful having an app that would allow:

• creation of new hgrc files
• first-time initialization of hgrc files
• validation of existing hgrc files
• tweaking existing hgrc files to add/change options and activate/deactivate available 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...)

Could be a plug-in: something like hg newconfig [-R [repo_path]] - Ask configuration questions. If a repository is specified, changes are applied to that repo, else they are set inside user directory.

Note: The ConfigExtension fills much of this void. It allows you to read/write arbitrary configuration values and it provides a number of simple dialogs for configuring username, web configuration, and repository paths. It includes a username hook that automatically prompts the user for a username if they try to commit without first configuring one.

7. 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

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

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

9. 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
• ...

10. 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 2006-12-07 09:43:51

11. Provide an extension to publish repos using just rsync/ftp

This extension would allow for a full serverless solution for publishing and accessing Mercurial repos.

It would allow to publish repos with just a ftp server or an rsync server, as most web hosting services have (even the free ones) and read them (to clone or pull changes) using using the static-http protocol.

A convenience command to browse the the remote repo history would be very good, even if that involves locally cloning the remote repo before using the log browser or launching the smart server to view it on a browser.

12. 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...

See the ProgressExtension. ÉricAraujo

13. 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; }}}

Note: The QctExtension supports a commit message template. You simply create a .commit.template file in your repository root.

14. 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 its webpage.

Note: The QctExtension supports a simpler model of change selection. You can select the individual changes to be included in a commit, and all remaining changes are left in the working directory after the commit.

I'd like to add that this feature is needed, because a workflow like QCT can really easily mean a broken build in the repo, as you have no way to test that the commit really works. Therefore something like shelves are mightily usefull. (I believe however that the MqExtension already allows this) --MartinHäcker

I believe this is 100% accomplished with the AtticExtension --BillBarry

+ add for a darcs-style interactive cherrypicking on commit (with a diff hunk granularity at least, maybe the possibility to split a hunk in sub-hunks before picking them)

See RecordExtension and CrecordExtension. There are plans (or perhaps just wishes) to integrate them to core commands. ÉricAraujo

15. New log styles

• Write the log as an Atom feed

• Write the log as coloured text — Isn’t that already possible with some ColorExtension configuration? ÉricAraujo

16. Add RSS feed for new repos to hgwebdir

Fairly self-explanatory, wouldn't you say? I want to keep abreast of what a person/organisation is doing, and they might not announce new repositories on their mailing list.

Useful idea indeed. I’d recommend using the Atom format, since it’s much better designed than all the various RSS formats. ÉricAraujo

17. A command to set configuration items

Rather than requiring the user to manually edit the mercurial.ini/.hgrc file, offer a command to set options. The most awkward aspect of this is choosing the correct file (probably ~/.hgrc on Unix, and <Documents and Settings>\<User>\Mercurial.ini on Windows) and editing the file in place.

Probably limit to setting values in the [ui] section (could add a --section NAME option to override?).

Examples:

    hg config username "A User <user@example.com>"
    hg config editor gvim

Arguably, the above two examples are the only ones likely to be useful... Bazaar has a bzr whoami command which handles the first.

The main benefit is likely to be to avoid giving new users the bad experience of having to edit a config file as one of their first actions after installing...

Note: The ConfigExtension fills much of this void. It allows you to read/write arbitrary configuration values and it provides a number of simple dialogs for configuring username, web configuration, and repository paths. The actual commands required to accomplish the above examples are:

    hg config ui.username "A User <user@example.com>"
    hg config ui.editor gvim

18. Clone&pull some parts of .hg/hgrc

There are some settings in .hg/hgrc which would be nice to have automatically synchronized on clone/pull. Namely: aliases for common important repositories, extensions crucial for given project to work correctly (like MQ), important project-related extension parameters (keyword maps for hgkeyword, newline conversion settings...).

Copying all those after every clone is troublesome, and fairly often those settings are not suitable for the global configuration.

What about in-repo configuration file, say .hgrc, which would be normally managed (just like .hgignore is)? Mercurial already loads hgrc-settings from a lot of places, so one more should not matter much.

19. Wire protocol improvements

Add a fine grained (revlog) changegroup command, that would allow to restart a broken connection.

Discover the missing nodes in a more clever way (less roundtrip), currently it takes quite a long time if you haven't updated in a while. For exemple, we could walk the unknown node from the server at the same time that we compute the nodes the server doesn't know.

20. Manifest command extension: edit file permission bits

Extending the manifest command to allow editing of the permission bits on systems where this is not natively supported. For example, on unix file systems, the permission bits of a tracked file can be changed and the commit command will record this in the history, and edit the manifest accordingly. Unfortunately, this means that users of file systems that don't support unix file permission bits can not set those bits using the existing commands. Their only hope is to be able to tell mercurial that the permission bits must be changed. This would then result in a revlog entry.

21. Transparent decompression of archives for version tracking

It would be nice if Mercurial could transparently decompress archive files.

For example that would make Open Document file versioning efficient.

22. Download files and folders through web interface

It would be good to be able to download a specific version of file through the web interface. (Already possible: click the "raw" link from the hgweb file view, for the relevant revision.)

It would also be good to be able to download a specific folder through the web interface, by a right clic for example (impossible for the moment).