Access command line arguments from In-Process Python hook

[durwin at mgtsciences.com]

Steve Hoelzer <shoelzer at gmail.com> wrote on 06/20/2014 01:18:10 PM:

> From: Steve Hoelzer <shoelzer at gmail.com>
> To: Durwin De La Rue <durwin at mgtsciences.com>
> Cc: Mercurial List <mercurial at selenic.com>, Matt Mackall 
<mpm at selenic.com>
> Date: 06/20/2014 01:18 PM
> Subject: Re: Access command line arguments from In-Process Python hook
> 
> On Thu, Jun 19, 2014 at 2:31 PM,  <durwin at mgtsciences.com> wrote:
> > Steve Hoelzer <shoelzer at gmail.com> wrote on 06/19/2014 01:24:51 PM:
> >
> >> From: Steve Hoelzer <shoelzer at gmail.com>
> >> To: durwin <durwin at mgtsciences.com>
> >> Cc: Mercurial List <mercurial at selenic.com>, Matt Mackall 
<mpm at selenic.com>
> >> Date: 06/19/2014 01:25 PM
> >> Subject: Re: Access command line arguments from In-Process Python 
hook
> >>
> >> On Thu, Jun 19, 2014 at 1:27 PM,  <durwin at mgtsciences.com> wrote:
> >> > Steve Hoelzer <shoelzer at gmail.com> wrote on 06/19/2014 12:04:35 PM:
> >> >
> >> >> From: Steve Hoelzer <shoelzer at gmail.com>
> >> >> To: durwin at mgtsciences.com
> >> >> Cc: Matt Mackall <mpm at selenic.com>, Mercurial List
> >> >> <mercurial at selenic.com>
> >> >> Date: 06/19/2014 12:04 PM
> >> >> Subject: Re: Access command line arguments from In-Process Python 
hook
> >> >>
> >> >> On Thu, Jun 19, 2014 at 10:33 AM,  <durwin at mgtsciences.com> wrote:
> >> >> > Normally when a new branch is pushed the option
> >> >> > --new-branch is specified. So using the force option for both 
normal
> >> >> > and
> >> >> > branch pushes is an acceptable method for what I am doing?  The
> >> >> > repository
> >> >> > will handle the forced push appropriately for both branch and
> >> >> > non-branches?
> >> >>
> >> >> The force option "will push all new heads on all branches" 
according
> >> >> to:
> >> >>
> >> >>
> >> > http://www.selenic.com/mercurial/hg.1.html
> >> >
> >> >>
> >> >> That sounds like what you want.
> >> >>
> >> >> Steve
> >> >
> >> > Thank you.  I've done some testing and it looks like it does the 
job.
> >> > What
> >> > has me a little concerned is the last part of the sentence,  "...an
> >> > action
> >> > which will almost always cause confusion for collaborators".
> >>
> >> The wording is not clear, but I think it is warning about getting
> >> multiple heads on a branch in a public or shared repo, a situation
> >> "which will almost always cause confusion for collaborators". Regular
> >> pushes (non forced) prevent that from happening, so these repos will
> >> never end up in that situation. (Well, unless someone has multiple
> >> heads in a private repo and does push -f.)
> >>
> >> Using push -f for syncing simply makes the repos mirrors of each 
other
> >> with all heads, and therefore all branches. If users don't push
> >> multiple heads per branch, the synched repos will never have multiple
> >> heads per branch.
> >>
> > Thank you.  That makes me feel better.
> 
> Actually, thinking about this more, there is a small chance that
> multiple heads could get created. Let's say two people are working on
> the same branch in their own clones. Then they both push at the same
> time, but one person pushes to repo A and the other pushes to repo B.
> Neither push creates multiple heads in the destination repo, so both
> will succeed, but the head in A is different from the head in B. Then
> the syncing happens with push -f and both repos end up with both
> heads.
> 
> I think this could only happen in very small windows of time. When a
> push begins to one repo, a 2nd push to the other repo would have to
> start before the 1st push completes. It's not likely, but it is
> possible.
> 
> It's also easy to fix. Just pull, merge the heads, and push. The
> syncing will mirror the new single head and everyone will get it when
> they pull.
> 
> Steve

Thank you for this insight.  For the small chance of this happening 
compared to the times I had to manually sync, I think it is acceptable. 
Should it occur, and both sides end up with 2 heads, everyone that does a 
pull afterwards should see the problem, correct??

Durwin


This email message and any attachments are for the sole use of the 
intended recipient(s) and may contain proprietary and/or confidential 
information which may be privileged or otherwise protected from 
disclosure. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient(s), please contact the 
sender by reply email and destroy the original message and any copies of 
the message as well as any attachments to the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140620/381e37a6/attachment-0002.html>