On Fri, Sep 11, 2009 at 11:15 AM, Yuki KODAMA <endflow....@gmail.com> wrote: > On Sat, Sep 12, 2009 at 00:37, Adrian Buehlmann <adr...@cadifra.com> wrote: >> 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. > > I agree. I prefer the simple repository graph on official repo. > And even If I could push changesets to the official repo directly, > I will send a patch to dev-ML maybe :) > However, to grant the write permission to another member as *backup* is > good idea. In fact, I'm a backup of i18n maintainer, Peer. > >> 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). > > Adrian, I did rethink this topic. The reason why I felt a bit odd of > your proposal > is it's your personal repository (sorry, but it's really...). > So If we have official crew repo that allows playing & hacking TortoiseHg for > experimental features & changes (and dirty rev graph by merging), > I will push my unstable codes to there :)
Shall I resurrect the crew repo and make you both writers? -- Steve Borho ------------------------------------------------------------------------------ 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
