On 09/05/2013 09:51 AM, Ehsan Akhgari wrote:
On 2013-09-03 9:39 PM, Aki Sasaki wrote:
On 9/3/13 8:25 AM, Ehsan Akhgari wrote:
2. How frequently are these branches updated?

The current job is running on a 5 minute cron job. We can, of course,
change that if needed. When I add a new repo or a slew of new branches
to convert, the job can take longer to complete, but it typically
finishes in about 6 minutes.

Sounds good, that's exactly the same setup and frequency that I have as
well.  It seems to be working fine for most people.

I had the same frequency before, but the problem is that when you are trying to push, you are 5 minutes late compared to the others. It happens to me, that I had to rebase multiple times before being able to push anything to inbound.

Since, I changed to a system which is looking every 10s for modifications in the pushlogs, then if there is a modification the script will update of the modified branch.

The reasons why I bring the timer so low, is that the pushlog is serve through http, and the server is likely to cache it knowing that this is used by tbpl (which by the way use https). I did not do it before because "hg id" still implies that we have to establish a secure connection.

Part of the value of having a git mirror for developers is that we don't
require individual people to have their own mirroring infrastructure, so
just providing documentation that tells people how to set up their own
branches by setting up hg-git locally, etc. is kind of defeating the purpose
of having a mirror that helps everybody.

I Agree.

This is for this exact reason that I move all this process to another computer. Having to use a special tool for pushing is a terrible git integration.

4. About the interaction between gecko.git and beagle, when you say that
they cannot be identical, are you talking about the location where they're
hosted or the SHA1s for the same commits?  I think we need to guarantee the
latter being identical going forward, but the former doesn't matter as much.

It's a requirement to keep the SHA1s the same, and we are confident we
can do that.
The location and naming for legacy b2g branches will be different, as
well as a hard fastforward-only rule on gecko.git.

That sounds fine.

One point to note here is that because of reasons which I have not explored,
some of our branches such as aurora and beta are regularly updated in a
non-fast-forward manner.  You can see this if you run git fetch in a local
clone (there will be a "(forced update)" next to the name of the branch in
the output.)  You might want to investigate why that happens in case B2G
starts to follow regular release trains in the future (but please also note
that it might just be a bug in my existing setup.)

I never experienced that before. I guess this might be related to the fact that I pull all mercurial repositories into one before doing the conversion to git.

--
Nicolas B. Pierron
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to