On 11.09.2009 16:56, Steve Borho wrote: > On Fri, Sep 11, 2009 at 4:48 AM, Adrian Buehlmann <adr...@cadifra.com> wrote: >> On 11.09.2009 10:25, Sune Foldager wrote: >>> On Friday, 11 September, 2009, at 10:03AM, "Adrian Buehlmann" >>> <adr...@cadifra.com> wrote: >>>> On 11.09.2009 09:30, Sune Foldager wrote: >>>>> I tried to post this yesterday but it seemed not to work. Maybe this time. >>>>> Sorry for the duplicate if it actually worked anyway :-p. >>>> IIRC, I pulled this yesterday already: >>>> http://bitbucket.org/tortoisehg/stable/changeset/2fd6e63dbd17/ >>> Ah ok, cool. For some reason the mail didn't get back to me, so I assume it >>> was lost :-p >> Steve decided to stop sending push notification emails some time ago. >> >> Just check http://bitbucket.org/tortoisehg/stable/overview/ >> >> There are also feeds available: RSS and Atom -- I never used them myself, >> I just manually check the website if I want to know if Steve has pushed >> my patches (or do 'hg inco'). If he's online, he's usually very quick at >> pushing. >> >> As a side note: I don't have push access, although I recently experimented >> with >> pushing some patches I was interested in to my bb fork repo during Steve's >> offline >> phase. Steve then reviewed and pull them from my bb repo in a batch when he >> was back >> online. > > I pretty much push everything Adrian and Yuki post to the -dev list. > If either of you wants write access to the main repo, I would be ok > with it. The only downside is the revision graph would probably > become more cluttered.
Hmm. It would be easy for me to take care not to inflict merges willy nilly. The downside is, if more people push to the official repo, we don't know who pushed what. Having a single pull model has its merits. Also, I don't do builds anyway. So its probably best if the person who makes builds does the final pulls into the "golden" repo. Knowing that "Steve has reviewed" what's in the official repo is nice as well. And I definitely lack your expertise. > If you guys want to maintain a common crew repo, that would be fine as > well, but the current patch scheme seems to work ok. Having to wait until you push a patch of Yuki has been a bit of a nuisance for me recently, as I was interested in having/trying Yuki's things, knowing that you most likely will push his patches anyway, as soon as you get online. So, my options were to apply Yukis patches locally and then strip them again as soon as you have pushed them. But hacking on top of that felt a bit stupid at times. For what's worth, I failed to convince Yuki to push into the same repo as I do. Separation can have its merits too :) But a crew repo could be nice indeed. But then we see merges between crew and main repo (like mercurial). ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
