Re: Continued work on sr/vcs-helper and sr/gfi-options

Sverre Rabbelier [off-list ref] writes:

quoted

 - Merge today's 'master' to sr/remote-hg (optional);

I'm not sure why this is though? (no objections against it, I just
don't understand the motivation)

It would make sense if you use 1.6.6 features in your new series (as the
forkpoint of sr/vcs-helper is beginning to look a tad stale), but
otherwise unnecessary; that is the reason why I said it is "(optional)"
and it is up to what is in the remote-hg patch.

quoted

 - Create an unstable sr/pu-remote-hg branch that:

  - is reset to the tip of sr/remote-hg at the beginning of the day;
  - merges the day's sr/gfi-options on top;
  - re-applies patches to implement Hg interoperation on top of the
    result.

Ok, that does make sense, how would I send out patches for review from
this unstable branch though? (since others would not have the required
merges etc) I reckon it would be necessary to publish sr/pu-remote-hg
somewhere?

I was thinking about carrying it myself (perhaps with help from you in
conflict resolution as necessary) when I wrote it, but if you want me to
pull from your repository somewhere e.g. repo.or.cz, that would also be
fine.

Heya,

On Mon, Dec 7, 2009 at 00:36, Junio C Hamano [off-list ref] wrote:

It would make sense if you use 1.6.6 features in your new series (as the
forkpoint of sr/vcs-helper is beginning to look a tad stale), but
otherwise unnecessary; that is the reason why I said it is "(optional)"
and it is up to what is in the remote-hg patch.

Gotcha, I don't think I use any 1.6.6 features though, so I don't
think that will be necessary.

I was thinking about carrying it myself (perhaps with help from you in
conflict resolution as necessary) when I wrote it

That would be great! If you are you offering to create the
sr/pu-remote-hg branch and merge it to pu so that I can send patches
based on that, please do. If not, what do I do instead? :).

-- 
Cheers,

Sverre Rabbelier