Hi Christian
On 05/31/2010 10:08 PM, Christian Lohmaier wrote:
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.
Agreed, it's probably not much of a problem if the server side rep. has
two heads for a short time frame. Prolonged phases with two heads could
be a problem if a CWS is shared by multiple developers and the second
head is not expected by some.
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...
Ah yeah, the magical touch of git which is able to make huge compressed
changesets much smaller, almost vanishing in size. :-) Git might have a
smaller storage for a given repository, granted, but I somehow doubt
that it's able to transfer huge changesets much faster than Hg. But
then, making these sarcastic jokes in IRC channels where I do hang
around might draw an informed response and that would certainly spoil
the fun :-)
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
Yep, that could happen on a weekend :-)
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)...
The sending client does not need to have these changes in place, so it
would fit quite nicely in our case here.
Regards,
Heiner
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
