Hi *,
On Mon, May 31, 2010 at 7:41 AM, Jens-Heiner Rechtien
<[email protected]> wrote:
> [...]
> a) Most important, if there are already developer changes in the CWS (which
> will be the standard case) such a "remote update" will create a new head
> which will be very confusing for many users, since we have adopted a strict
> "one head only" policy for the outgoing repositories.
I don't see this as a problem, as the pull is triggered so that the
merge-push of the developer doesn't take that long. The intention is
to trigger the remote-pull, wait a minute or two, then push the merge
that is done locally already.
So yes, there will be two heads, but just for the minute or two the
developer has to wait for the remote pull to complete.
This opposed to half an hour or more for a complete push is quite a difference.
> Remote merge is not
> possible (no working trees, no one to solve potential conflicts).
Well, no need for remote merge, just for getting all those
unrelated-to-the-actual-cws commits faster
The developer still merges locally.
> b) It doesn't really fit into the framework.
Too bad :-(
> [...] Thus the only way to implement that would be the introduction
> of a new flag ("remote_pull_requested") in EIS which would than be polled by
> another server side script.
Too bad. If it is polled, and not executed right after it was
requested, it will be very hard to determine when the real push of the
merge can start :-/ - sending an email when it is done would be the
only solution. But if that it is only polled every 5 hours, then that
delay again outweighs the benefit :-/
> [...] Not sure if this added complexity is worth
> the IMHO quite narrow use case - it's the first time I've heard such a
> request.
That I'm the first to voice it in a concrete request doesn't mean that
I'm the first to complain. Hang out on the corresponding IRC channels,
and you'll tons of complaints or sarcastic jokes (usually followed by
how much more that developer loves git ;->) about that...
> I'm always willing to lend a hand with the CWS update if someone sends me an
> email with such a request. If I receive many such requests I'll certainly
> consider to automate this :-)
Depends on the roundtrip I guess. As for me it would very likely be
week-end, Waiting for your intervention/reply would be longer than
clogging my bandwidth overnight :-P
> PS: It's an interesting idea to implement in a server side extension of
> Mercurial: If, during a push to remote, a comparison of the local rep.
> changesets with the remote changesets yields a list of changesets which are
> not yet remote available, consider first to consult another remote "well
> known reference" repository for the changesets, pull any possibly available
> changesets from there and then renegotiate the list of missing changesets
> with the local repository. Don't know if this is easy to implement but it
> could be worthwhile for monster repositories as well (like OOo). Thinking
> about it, it's even an option for the local side on a pull.
Yes, that would do the trick as well, although that (in my eyes) seems
to be more complicated to implement (as it seems would require changes
to the client as well, but I don't have no understanding whatsoever on
how pushing and receiving side decide on what needs to be transferred
and what is already available on the receiving side)...
ciao
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
