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

[Angel Ezquerra]

On Thu, Mar 6, 2014 at 12:35 PM, Simon King <simon at simonking.org.uk> wrote:
> 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?

Actually I first started using a separate file inside the .hg folder
and then I changed it so that the current unfinished implementation
uses local tags, not regular tags. However I think that I must record
it "in history" so that more than one user can link its local
repository clone to their own TF workspace.

Angel