Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
On Thu, 03 Jun 2010 19:04:52 +0200 Jan Holesovsky ke...@suse.cz wrote: Just as mercurial would do if we would be using a multiple head repo instead of multiple heads. So git is no more magical there than hg. ;) Oh sure, but then again, 'named branches' feature was terribly unstable at the time Mercurial was evaluated, and I am not sure they ever got removing named branches right. Named branches where not unstable in hg -- they were just ... ahem ... different. They are a solution comparable to our codelines (DEV300/OOO320). Feature branches where never an intended usecase for them. For that, mercurial has bookmarks and those are stable since ages. Your repos on the server would grow substantially, while with git (with the alternates setup - one line!) they would not. Even after the push, they'd grow just by the amount of data that was actually transferred (as explained, a small fraction of what is pushed now), nothing more. Wrong. Pushing/Pulling completely locally on the remote server would be just creation of hardlinks and would not require additional copies of the changesets. So, no: there is no advantage for git here. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi Heiner, Jens-Heiner Rechtien píše v Út 01. 06. 2010 v 15:32 +0200: [...] 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. Indeed, git is magical ;-) In this case, on the server, the CWS wouldn't be separate trees, but branches (in the git meaning of the word), and so you wouldn't have to push all the changes that happened in DEV300 in the meantime (if you have them in another brach, they are reused) - ie. exactly what Christian wants. And even if they were separate trees, you are able to setup the trees (CWSes in this case) trivially to search for the missing commits (and objects, etc.) in the main tree (DEV300) first using 'alternates', before expecting the client to push them all. So, you wouldn't even need a special cws command to get the changes that happened in DEV300 into the remote CWS tree first, and still you'd save the push bandwidth. Regards, Kendy - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Am Thu, 03 Jun 2010 17:28:00 +0200 schrieb Jan Holesovsky ke...@suse.cz: 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. Indeed, git is magical ;-) In this case, on the server, the CWS wouldn't be separate trees, but branches (in the git meaning of the word), and so you wouldn't have to push all the changes that happened in DEV300 in the meantime (if you have them in another brach, they are reused) - ie. exactly what Christian wants. Just as mercurial would do if we would be using a multiple head repo instead of multiple heads. So git is no more magical there than hg. ;) And even if they were separate trees, you are able to setup the trees (CWSes in this case) trivially to search for the missing commits (and objects, etc.) in the main tree (DEV300) first using 'alternates', before expecting the client to push them all. Again that would actually be just as trivial with hg if we would not have that one head repos!!1!eleven! dogma. For example a hook could simply pull from DEV300 before applying a changeset. Or even simpler a cronjob pulling from DEV300 to the cws repos regularly would solve the problem. IMHO most devs are able to handle a two-head (master and cws) repo easily by now. But I guess Heiner has another opinion. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi, On 06/03/2010 05:55 PM, Björn Michaelsen wrote: Am Thu, 03 Jun 2010 17:28:00 +0200 schrieb Jan Holesovskyke...@suse.cz: 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. Indeed, git is magical ;-) In this case, on the server, the CWS wouldn't be separate trees, but branches (in the git meaning of the word), and so you wouldn't have to push all the changes that happened in DEV300 in the meantime (if you have them in another brach, they are reused) - ie. exactly what Christian wants. Never in life I would want to have all branches (CWSs) in one repository. No way. Not with hg and not with git. Such things work well in a pull-only environment. But when every dev can push something to the rep. they need necessarily be separated - so I can simply drop the whole rep. if someone pushes something very stupid. And yes, these things happen. Just as mercurial would do if we would be using a multiple head repo instead of multiple heads. So git is no more magical there than hg. ;) And even if they were separate trees, you are able to setup the trees (CWSes in this case) trivially to search for the missing commits (and objects, etc.) in the main tree (DEV300) first using 'alternates', before expecting the client to push them all. This is exactly what I meant with reference rep. in the postscriptum of my mail to Christian. I'll look into it if this is possible with mercurial. Again that would actually be just as trivial with hg if we would not have that one head repos!!1!eleven! dogma. For example a hook could simply pull from DEV300 before applying a changeset. Or even simpler a cronjob pulling from DEV300 to the cws repos regularly would solve the problem. IMHO most devs are able to handle a two-head (master and cws) repo easily by now. But I guess Heiner has another opinion. Most devs ..., yes. But we need everyone to handle this right. Remember, there are non-devs who also need to work with the setup. And, judging by the questions I have been answering lately, we aren't yet there to try out the fancy stuff :-) Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi Bjoern, Björn Michaelsen píše v Čt 03. 06. 2010 v 17:55 +0200: Indeed, git is magical ;-) In this case, on the server, the CWS wouldn't be separate trees, but branches (in the git meaning of the word), and so you wouldn't have to push all the changes that happened in DEV300 in the meantime (if you have them in another brach, they are reused) - ie. exactly what Christian wants. Just as mercurial would do if we would be using a multiple head repo instead of multiple heads. So git is no more magical there than hg. ;) Oh sure, but then again, 'named branches' feature was terribly unstable at the time Mercurial was evaluated, and I am not sure they ever got removing named branches right. And even if they were separate trees, you are able to setup the trees (CWSes in this case) trivially to search for the missing commits (and objects, etc.) in the main tree (DEV300) first using 'alternates', before expecting the client to push them all. Again that would actually be just as trivial with hg if we would not have that one head repos!!1!eleven! dogma. For example a hook could simply pull from DEV300 before applying a changeset. Or even simpler a cronjob pulling from DEV300 to the cws repos regularly would solve the problem. Your repos on the server would grow substantially, while with git (with the alternates setup - one line!) they would not. Even after the push, they'd grow just by the amount of data that was actually transferred (as explained, a small fraction of what is pushed now), nothing more. Anyway - sorry, I don't want to start another git vs. hg flamewar ;-) Regards, Kendy - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
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 jens-heiner.recht...@sun.com 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: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
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 -mmilestone 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: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
On 05/27/10 19:12, Christian Lohmaier wrote: 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. It would be cool if hg -R ssh://h...@hg.services.openoffice.org/cws/mycws \ pull http://hg.services.openoffice.org/DEV300 did what one would hope it would do. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Hi Christian, I seem to have some problems understanding what you want! If you would do such a 'remote pull' for a new milestone on the remote cws hg repository wouldn´t you than need to pull these changes done on that remote cws hg repository into your local hg repository afterwards before you can than push your own changes in order to resolve merge conflicts and to not create two mercurial heads on the remote hg repository and wouldn´t that mean that in fact nothing is gained at all? Kind regards, Bernd Eilers 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: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] cws tools: Would a remote pull of a given milestone to accelerate cws rebasing be possible
Am Fri, 28 May 2010 12:42:01 +0200 schrieb Bernd Eilers bernd.eil...@sun.com: If you would do such a 'remote pull' for a new milestone on the remote cws hg repository wouldn´t you than need to pull these changes done on that remote cws hg repository into your local hg repository afterwards before you can than push your own changes in order to resolve merge conflicts and to not create two mercurial heads on the remote hg repository and wouldn´t that mean that in fact nothing is gained at all? No. Without a remote pull you have to: - pull from DEV300 to local (all master changes) - merge local - push from local to remote cws (all master changes and merge changes) With a remote pull you have to: - pull from DEV300 to local (all master changesets) - remote pull (actually just hardlinking on hg.services...) - merge local - push from local to remote cws (_JUST_ merge changesets) Given the size of changes on the master there is a lot of bandwidth (and storage on the hg.services... server) to be saved. The gain is again multiplied if devs have multiple local cws and a prestine local DEV300 copy. In that case the step: - pull from DEV300 to local (all master changes) is only performed once and not once per cws (local pulls dont cost bandwidth or storage), so the whole cost of the resync is in the: - push from local to remote cws step. And most of the transmitted changesets (the master changesets) are already on the remote site (in the DEV300, but not yet in the cws repo). BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
