Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible
Christian Lohmaier <[email protected]> Mon, 31 May 2010 16:08:05 -0400
| Newsgroups | gmane.comp.openoffice.devel.tools |
|---|---|
| Message-ID | <[email protected]> |
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