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

[Simon King]

On Thu, Mar 6, 2014 at 11:20 AM, Angel Ezquerra
<angel.ezquerra at gmail.com> wrote:
> 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).

Could you use local tags to avoid the extra commits? Or just have a
separate file that tracks the mapping between TFS and hg changesets?

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