Hi Christian,
ADSL being what it is, a push to an old CWS which has been updated to a
more recent milestone can be quite slow, especially if one of the
milestone contains a whole set of new localizations, agreed.
I've thought about a "remote update" of the outgoing repositories, but
it isn't that easy.
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.
Remote merge is not possible (no working trees, no one to solve
potential conflicts).
b) It doesn't really fit into the framework. The repositories are quite
independent from EIS, the only way to change the content of a outgoing
repository is via a push over ssh with a hg client, using the hg
protocol (which has no provision for this). EIS has no direct access to
the repositories (nor should it have), the only connection between the
two is a little script on the server which regularly polls EIS for new,
not yet created CWSs. 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. Since the execution and
succesful termination of that script isn't easily observable from the
outside, the script would additionally need to send emails. 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.
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 :-)
Regards,
Heiner
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.
On 05/27/2010 07:12 PM, Christian Lohmaier wrote:
Hi *,
As rebasing a cws with ADSL is a pain because of the slow upload link,
I wondered whether it would be possible to add a
cws pullremote -m<milestone> or similar command to cwstools.
Those would then pull the changes up to that given milestone into the
remote cws clone.
Thus the only thing that would be pushed from the developer's machine
would be the actual merge commits. Much less bandwidth spent that way,
and even more important: Much time saved.
Would it be possible to add that functionality?
ciao
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
