On 12.09.2009 04:57, Yuki KODAMA wrote: > On Sat, Sep 12, 2009 at 02:22, Adrian Buehlmann <adr...@cadifra.com> wrote: >> On 11.09.2009 18:27, Steve Borho wrote: >>> Shall I resurrect the crew repo and make you both writers? >> No thanks. Not needed any more. > > If Adrian doesn't need crew repo, I also don't need it. > The importance of existence of crew is early sharing of our (Adrian & me) > changesets till Steve back to online. > Sorry for bothering you, Steve. >
Given the layout of the time zones, I would probably have been the only one possibly benefitting of such a repo. Yuki is GMT+9, I am GMT+2, Steve is GMT-5. So I am the man in the middle (regarding time zones). So, in the morning, I pulled Steve's changes and saw Yuki's patches he sent to the list hanging in the queue. In that past, I had in some cases seen a benefit in using Yuki's work *before* Steve has reviewed and pushed them. I saw little point in applying them myself to my work repo, then stripping them again and pulling Steve's pushes when he applied them. Especially not after having learned that Steve pushed pretty much anything of Yuki anyway. It is obvious that Yuki is not interested in having early access to my changes. Neither does Steve, since he does his big hacks in the his evening, when I'm already sleeping. However, it was interesting to see how difficult it is to change workflows, even on such a tiny project :). It was especially funny to learn afterwards, that it was just the URL of the repo that was the problem. In my book, all changesets that a contributor publishes anywhere with a request to include them are "official" changesets. It doesn't matter *where* they are published. If anyone sends a patch to the tortoiseHg devel mailing list, I suppose he wants that included in the main repo and thus appear in the next release. I don't know why a repo on bitbucket created by person X should be more official than if it is created by person Y. Sepcifically, why do we need Steve to create a repo called "crew", so that team members will use that repo to push changes there? If all team members can push there anyway? It is interesting to see that the power of mercurial wasn't even applied on this project itself. Mercurial is used here for working independently by a number of individuals, sending their work to one central "master" developer, without exchange of changes between those non-master developers. The working style is still a central one, but with the benefit of contributors being able to work disconnected from the central repo. In that sense it still resembles a lot with the SVN model, with the important difference that SVN does not support local commits and contributors always need connectivity to access project history. But obviously, this is more a social and communication problem than anything else. Sorry for having bothered you, Yuki. I hope you do continue contributing as you did despite my failed attempt in tweaking TortoiseHg workflows. My attempt was also motivated to see mercurial used in a real project. Otherwise I wouldn't probably have bothered at all. ------------------------------------------------------------------------------ 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
