cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Christian Lohmaier-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Bernd Eilers

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Christian Lohmaier-2
Hi Bernd, *,

On Fri, May 28, 2010 at 6:42 AM, Bernd Eilers <[hidden email]> wrote:
>
> I seem to have some problems understanding what you want!

I'll try to explain in more detail...

> 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

Well, no as no "changes" were done on that remote repository. I can
just as well pull from my local up-to-date pristine DEV300 clone.
And even if I could not do that and would have to pull the new
milestone as well, the my downstream is much,much faster than my
upload capacity.

> before you
> can than push your own changes in order to resolve merge conflicts and to
> not create two mercurial heads

I create a cws this will create a remote clone, I create a clone from
that (or clone from my local DEV300 clone) and make changes to that
local copy.
I push those changes to the remote cws clone.
<iterate, time goes by>
In the meantime, new masters have been created, I need to rebase. So I
pull that new master into my local cws clone. Merge resolving, etc,
commit locally.

Now is where the pain starts.

Currently, I have to push everything to the remote cws clone. Not just
my own changes, but everything that changed between the milestone the
cws was based on and the new desired milestone. With ADSL (and thus
slow upload) this is a pain, if it is done in half an hour you're a
lucky one.

When however, I could initiate that same pull  to the remote cws
clone, I would only have to push the changes needed for the actual
merge.
So yes, initially there would be two heads, that are resolved after
the merge commits are pushed.

> on the remote hg repository and wouldn´t that
> mean that in fact nothing is gained at all?

I hope it is more clear now.

ciao
Christian
PS: I also don't clone the a cws, I pull it into a local clone, that
results in an additional head, but I can just update to that and
forget about heads from that point. But that way I don't have to
download ~ 1GB of data, but just the actual changes. The same thing in
the other direction is what I want.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Björn Michaelsen-2
In reply to this post by Bernd Eilers
Am Fri, 28 May 2010 12:42:01 +0200
schrieb Bernd Eilers <[hidden email]>:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Jens-Heiner Rechtien
In reply to this post by Christian Lohmaier-2
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

stephan.bergmann
In reply to this post by Christian Lohmaier-2
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://[hidden email]/cws/mycws \
    pull http://hg.services.openoffice.org/DEV300

did what one would hope it would do.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Christian Lohmaier-2
In reply to this post by Jens-Heiner Rechtien
Hi *,

On Mon, May 31, 2010 at 7:41 AM, Jens-Heiner Rechtien
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Jens-Heiner Rechtien
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
> <[hidden email]>  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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Jan Holesovsky
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Björn Michaelsen-2
Am Thu, 03 Jun 2010 17:28:00 +0200
schrieb Jan Holesovsky <[hidden email]>:

> > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Jens-Heiner Rechtien
Hi,

On 06/03/2010 05:55 PM, Björn Michaelsen wrote:

> Am Thu, 03 Jun 2010 17:28:00 +0200
> schrieb Jan Holesovsky<[hidden email]>:
>
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Jan Holesovsky
In reply to this post by Björn Michaelsen-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Björn Michaelsen-2
On Thu, 03 Jun 2010 19:04:52 +0200
Jan Holesovsky <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Björn Michaelsen-2
In reply to this post by Jens-Heiner Rechtien
Am Thu, 03 Jun 2010 18:49:53 +0200
schrieb Jens-Heiner Rechtien <[hidden email]>:

> > 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 :-)

Hmmm, how about a checkbox in EIS "automatically pull from master"? A
cronjob could then automatically pull from master to all cws where the
checkbox is set. Of cause, the checkbox is marked with "experimental,
will eat your kitten, dont touch" so only the brave and few will use it
and will be on their own when they make mistakes.

How about that?

Best Regards,

Bjoern

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: cws tools: Would a "remote pull" of a given milestone to accelerate cws rebasing be possible

Jan Holesovsky
In reply to this post by Björn Michaelsen-2
Hi Bjoern,

Dne Friday 04 of June 2010 09:47:02 bjoern michaelsen - Sun Microsystems -
Hamburg Germany napsal(a):

> > 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.

Are you sure?  This is of course true for cloning, but from what I see,
everything that has branched (ie. every file that has different history in
those two repositories) is tracked on its own, and cannot be hardlinked.  
Similarly changelogs and manifests (which are the painful hits - more than
300M for DEV300 per CWS).  But maybe I just don't understand Mercurial
enough - sorry in that case.

Anyway, we are really getting off-topic.

Regards,
Kendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]