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

[Angel Ezquerra]

On Thu, Mar 6, 2014 at 12:54 PM, Simon King <simon at simonking.org.uk> wrote:
> On Thu, Mar 6, 2014 at 11:43 AM, Angel Ezquerra
> <angel.ezquerra at gmail.com> wrote:
>> 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.
>>
>
> Fair enough.
>
> In answer to one of your earlier questions, about having to rewrite
> commands.commit, you could avoid that with a very ugly hack, passing
> the extra data in via the config object. You could even do that from
> the command line:
>
> hg ci --config tfs.changeset=xxx
>
> You would then wrap localrepo.commit, get it to pull the data it wants
> from the config and put it in the extra dict.
>
> (As a proper solution this is horrible, but it seems like the least
> invasive way to get the behaviour you want)

That is neat but as you say also pretty "horrible" (in a kind of
awesome way :-) )

Angel