[PATCH] commit: add --extra argument to set extra user fields

[Angel Ezquerra]

On Thu, Mar 6, 2014 at 11:42 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 03/06/2014 08:59 AM, Angel Ezquerra wrote:
>>
>> I'm trying to create a mercurial-TFS bridge
>
>
> Have you considered implementing convert source and sink for TFS?
>
> /Mads

That is something that could be done (and I may do it). However, I
don't think that lets you have a bidirectional bridge, does it? I
haven't used convert much so please correct me if I am wrong...

I think what I'm trying to make is something similar to hggit or
hgsubversion (although I have not actually used those myself, so the
similarity may only be superficial).

It is not ready yet (I will share it when it is) but what I am doing
is adding 3 new commands that let you link a mercurial repo to a TFS
workspace and pull from / push to that TFS workspace:

- tflink: Link an existing mercurial repository to an existing TFS
branch workspace. This simply stores a TFS "branch_name" to local TFS
folder relationship on a config file).

- tfpull: Gets new TFS changesets from a linked TFS branch into a
mercurial repository. These are converted into mercurial revisions
that are made on a particular branch (called TFS.TFS_BRANCH_NAME by
default).

- tfpush: take the mercurial revisions that descend from the latest
imported TFS revision and convert them into TFS changesets. This is
tricky because TFS history must be purely linear (as in SVN). This
means that we need abort if there are multiple heads for example. We
also need to detect when the history is not linear, and in that case
choose which revisions to "push" (either always taking one of the
parents or by asking the user what to do).

Currently these commands are executed by running a stand alone
"hgtf.py" script, but I may create a proper mercurial extension and
convert them into mercurial commands instead.

To "mark" imported revisions I had planned to embed the unique TFS
changeset ID in extra.user.tfs. Perhaps a better strategy is to just
add tags. I would want to avoid creating two revisions per TFS
changeset (1 regular revision + 1 tag revision) so perhaps I will try
to create all the tags on a single commit (by tagging at the end and
folding the tag commits or by automatically updating the .hgtags file
in a single go).

I have also considered adding a new type of subrepo (tfsubrepo). This
should be pretty simple I think, and very similar to the existing
svnsubrepo. The main issue I see is that this is not something that
can be easily tested with mercurial's test suite, since it requires
access to a proprietary Team Foundation Server.

Cheers,

Angel