Creating a dummy bundle (containing only changeset metadata but not changeset contents)

[Pierre-Yves David]

On 04/16/2014 06:34 PM, Angel Ezquerra wrote:
> On Mon, Apr 14, 2014 at 4:02 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>
>> On 04/14/2014 03:40 AM, Angel Ezquerra wrote:
>>>
>>> Hi,
>>>
>>> I am writing an extension to use mercurial as a local client for
>>> Microsoft's Team Foundation Server (i.e. TFS). It is somewhat similar
>>> to hgsubversion and hggit. It is not done yet but already quite
>>> functional. It is pretty well integrated with TortoiseHg, making it
>>> possible to use the pull, outgoing and push buttons in TortoiseHg (and
>>> the corresponding mercurial command line commands) to get/send data
>>> from/to TFS.
>>>
>>> However, the integration with the "hg incoming" command is not that
>>> good. When using the command line you can do "hg incoming TFS_PATH"
>>> (where TFS_PATH is an alias pointing to a "tfs://tfs_worskpace_path")
>>> to get a list of incoming changesets. However TortoiseHg uses
>>> "incoming --bundle" to avoid having to speed up the pull that usually
>>> follows the call to incoming. The problem is that in order to support
>>> that workflow I would need to create an hg bundle.
>>>
>>> I could make "hg incoming --bundle" do a pull and then convert the
>>> pulled revisions into an actual hg bundle. However a full pull
>>> operation from TFS is expensive, whereas just listing the incoming
>>> changesets is not. Thus I would prefer to create a "dummy bundle" that
>>> only contained the information about the TFS changesets that would be
>>> pulled (i.e. the changeset number, author, date and commit message)
>>> but none of the actual file contents. Ideally I'd like to be able to
>>> put some metadata on the bundle that can be detected by the
>>> extension's pull wrapper, which would trigger the actual TFS pull
>>> operation.
>>>
>>> So, is there an easy way that I can construct a dummy bundle in this way?
>>
>>
>> You probably want to start playing around with bundle2. Specifically how to
>> plug that with bundlerepo.
>
> I thought about this, but I'd like my extension to be compatible with
> older mercurial versions (at least with the current version!).
> Any other ideas?

You can do something with pushkey then.

-- 
Pierre-Yves