Alternative behaviours in case of origin URL change

[Georges Racinet]

If one changes URL of a hg-versionned addons directory in the config file, this is ignored.
This is because the recipe does a bare pull (hg pull -u) instead of an explicit one (hg pull URL && hg update REVSPEC).

This is delicate matter. Developers are expected to use the recipe for a quick working environment.
At first run, the recipe does a clone, with has the effect of setting the default path in hgrc for subsequent bare pulls.
While they work, I suppose that they'll pull manually.

If the recipe does a pull/update on a new URL. that won't update the hgrc. Changes of branches may also lead to loss or severe conflicts for uncommitted changes (and hg default behavior in case of conflicts is aweful, especially for automated processes).

Perhaps the recipe should

1. Check if there are uncommitted changes
2. Raise something if this is a change of location and branch and there are uncommitted changes.
3. Optionnally update hgrc or issue a warning

Advices ?

[Georges Racinet (gracinet)]

Here's the decision after a little internal discussion at Anybox.

There'll be a new option, vcs-uncommitted-changes, with three values: forbid, discard and merge

In "forbid" mode, the recipe will raise an exception if there are uncommitted changes during the pull/update (in a second shot, only if the update part is not about a tag or explicit revision which can be identified as being current, ie there's no true update. The best would btw to detect this early and don't even try to pull or update, but that's a different issue of optimisation strategy)

In "discard" mode, the update will discard any uncommitted changes (in Mercurial, that's hg pull -C REVSPEC)

In "merge" mode, a normal pull/update is issued which can lead to merging the local changes and can have conflicts.

"forbid" should be the preferred choice for a production deployment, and should be default. A user non aware that the buildout will try updating would not risk messing up his working trees, and can be issued an explanatory log.

"discard" is ideal for a continuously watching bot.

[Georges Racinet (gracinet)]

Also, in case of an URL change, the path should be updated in repo's hgrc and the previous one kept as "buildout-previous".

These changes will save the developpers much time in case of VCS reorganizations, and is almost necessary for bots

[Georges Racinet (gracinet)]

Update of repo's hgrc committed

This solves the problem of updates in bots in case of URL changes, but does not yet implement the safeguards mentionned earlier (vcs-uncommitted-changes). In other words, we have the 'merge' behaviour.

[Georges Racinet (gracinet)]

Had to release 0.15 for other reasons with this partial yet consistent state.

[Georges Racinet (gracinet)]

Changed title to better reflect what this issue now means