mq usage outline

Samuel Masham samuel.masham at gmail.com
Wed Nov 30 03:22:40 UTC 2005


Hi Daniel, Chris, All

On 30/11/05, Daniel Santa Cruz <byteshack at gmail.com> wrote:
> I might not understand all the angles, but here are my 2c.
>
> Would having more than one repository work for your third use case?
> The one that you seem more interested in?

The 3rd case is the only one with major issues at the moment. Hence
worth talking about :)

Daniel:
> Basically, you would have:
>
> 1. Your "working" repository (call it repoMINE) which is basically
> upstream + your queue of patches.
>
> 2. Your export repository (call it repoEXPORT) wich is upstream + your
> patches applied.

This wouldn't work in itself though it may be part of the solution.
The problem is that the version tree is broken and it doesn't really
matter how many copes of the tree there are.

To try and clarify I have written a tiny script to reproduce a
(blatant) aspect of the issue which I attach here.

Chris wrote:
>Ah, ok.  The perfect usage model for this is difficult to see, but it is
>definitely a valid usage.  The mq repo on serpentine.com is one example,
>and the end user experience is a little...odd.

that's how I first found the issue *grin*

Chris again:
>If everyone using your repo is mq aware, they can include push/pop in
>their update process.  I think this would be ideal, they pull both the
>l-k repo and your patches repo and push/pop normally.

Which was a large part of my reason for looking at the autosync
behavior at first. Then if you just clone both repositories it will
work at any point in time.

I am not certain that this is the only or best solution however,
especially when it comes to the cloned qrepos having different changes
in... so still looking.

last word from Chris:
>But, please feel free to experiment ;)

will do

Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue.sh
Type: application/x-sh
Size: 1001 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20051130/e614d83d/attachment-0001.sh>


More information about the Mercurial mailing list