{"thread":{"id":"20769","subject":"[RFC] teamGIT bonjour support","startedAt":"2009-08-28T07:02:39Z","lastAt":"2009-11-20T09:49:32Z","messageCount":10,"participants":["Abhijit Bhopatkar","John Tapsell","Ben Hoskings","Jakub Narebski","Petr Baudis","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121978","messageId":"2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com","threadId":"20769","inReplyTo":null,"subject":"[RFC] teamGIT bonjour support","fromName":"Abhijit Bhopatkar","fromEmail":"bain@devslashzero.com","sentAt":"2009-08-28T07:02:39Z","receivedAt":"2009-08-28T07:02:39Z","isPatch":false,"sender":{"key":"bain@devslashzero.com","avatar":"https://gravatar.com/avatar/3f9bfde580be8d4de9df5a129387d9069d43eb1a65d745c583de9dfe9d97ebc8?d=mp&s=160"},"body":"Hi,\n\nAfter a long pause in the development, i am back to drawing boards for teamGit.\n\nEver since i adopted git as my preferred version control system for my\nteams, I had this tough time keeping up with every one. Of course this\nis a GoodThing(TM) since this means pace of development is rather\ngood. But it has its usual problems of forcing everyone to religiously\npublish _AND_ keep rebasing on main branch every so often. Also my\nmajor problem is that we discover conflicts only _after_ a developer\ntries to rebase his work, typically (by design) after he has fully\ncoded and tested a feature.\n\nThe current way to get around this is shouting aloud before you start\nworking on a new feature/file/section.\nHowever    a. this is not scalable\n                b. pron to human errors\n               c. pron to inhumane erros and after fights ;).\n\nSo in this regards, I have on my drawing boards a rough design to\n1. Publish the current selected topic trees info on local lan.\n2. Keep track of interesting topic branches and add alerts when\nconflicts bet. selected trees reach alarming levels.\n3. Possibly later add authentication mechanism to restrict access.\n\nI plan to do this on LAN using bonjour service discovery, and rest\ncompletely being handled inside teamGIT running as a daemon(may be in\nwidely abused systray?). (Git will handle actual fetch/conflict\nchecking etc.)\nOn a side note i also plan to generate daily reports and configurable\nnotifications.\n\nSo I ask you people, is there a solution already cooking someplace?\nmay be something i can integrate with teamGIT? (e.g. bonjour plugin\nfor git dameon)\nAny thoughts or comment?\nAm i just too stupid to not manage it with documented company wide policies?\n\nBAIN\n"},{"id":"121980","messageId":"43d8ce650908280105x70327db0p7fce1bd6575297d2@mail.gmail.com","threadId":"20769","inReplyTo":"2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com","subject":"Re: [RFC] teamGIT bonjour support","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-08-28T08:05:54Z","receivedAt":"2009-08-28T08:05:54Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/8/28 Abhijit Bhopatkar :\n> Hi,\n>\n> After a long pause in the development, i am back to drawing boards for teamGit.\n>\n> Ever since i adopted git as my preferred version control system for my\n> teams, I had this tough time keeping up with every one. Of course this\n> is a GoodThing(TM) since this means pace of development is rather\n> good. But it has its usual problems of forcing everyone to religiously\n> publish _AND_ keep rebasing on main branch every so often. Also my\n> major problem is that we discover conflicts only _after_ a developer\n> tries to rebase his work, typically (by design) after he has fully\n> coded and tested a feature.\n\nWhat sort of time frame are you talking about? How long are your\nsprints, or however you partition your work.\n\nI can't help but feel the problem should be solved elsewhere. Do you\nhave daily scrums? Everyone should know, roughly, what everyone is\ndoing. If you are using 2-3 week sprints (or however you partition\nthe time) and everyone is roughly aware of what everyone else around\nthem is doing, there shouldn't really be so much of a problem.\n\n> The current way to get around this is shouting aloud before you start\n> working on a new feature/file/section.\n\nHow do you allocate the features in the first place? At the start of\na sprint? If so, it should be the person in charge of that that\nshould see if there are going to be conflicts. If you don't have\nsprints, then how do you divide up tasks?\n\nJohn\n"},{"id":"121984","messageId":"2fcfa6df0908280139q66051a4aubc9b289b46f50b43@mail.gmail.com","threadId":"20769","inReplyTo":"43d8ce650908280105x70327db0p7fce1bd6575297d2@mail.gmail.com","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Abhijit Bhopatkar","fromEmail":"bain@devslashzero.com","sentAt":"2009-08-28T08:39:13Z","receivedAt":"2009-08-28T08:39:13Z","isPatch":false,"sender":{"key":"bain@devslashzero.com","avatar":"https://gravatar.com/avatar/3f9bfde580be8d4de9df5a129387d9069d43eb1a65d745c583de9dfe9d97ebc8?d=mp&s=160"},"body":">> good. But it has its usual problems of forcing everyone to religiously\n>> publish _AND_ keep rebasing on main branch every so often. Also my\n>> major problem is that we discover conflicts only _after_ a developer\n>> tries to rebase his work, typically (by design) after he has fully\n>> coded and tested a feature.\n>\n> What sort of time frame are you talking about? How long are your\n> sprints, or however you partition your work.\n>\n> I can't help but feel the problem should be solved elsewhere. Do you\n> have daily scrums? Everyone should know, roughly, what everyone is\n> doing. If you are using 2-3 week sprints (or however you partition\n> the time) and everyone is roughly aware of what everyone else around\n> them is doing, there shouldn't really be so much of a problem.\n\nWell as i said in informal way we do shout out loud (managers: read as\n'daily meetings') when we want to make changes that might conflict\nwith some one else and i have been blessed with a rather good dev team\nwho can spot this right, and it works well for now for these short\nsprints. However see below for my itch.\n\n>> The current way to get around this is shouting aloud before you start\n>> working on a new feature/file/section.\n>\n> How do you allocate the features in the first place? At the start of\n> a sprint? If so, it should be the person in charge of that that\n> should see if there are going to be conflicts. If you don't have\n> sprints, then how do you divide up tasks?\n\nYes as i said this generally works.\nBut and this is a big BUT, this essentially makes the developer the\npoint of failure (in reporting the conflict). And in my view (exactly\ncontrary to yours) the problem should be solved else where.\n\nAlso we are working on many porting projects which need changes to the\nsame file but not essentially logically conflicting, which if,\neveryone is aware of at the moment the change is made (commited?) is\ntrivial to resolve.\nHowever when you have 100 such changes at the end of a sprint thats a\nproblem. Yes git makes it extremely easy to merge i can't even begin\nto think about the current style of development in svn deployment. And\nwe can resolve those conflicts fairly easy. Its just that I have to\ndepend then on individual's ability to persist through what seems like\nmillion merge conflicts.\nAnd no its not avoidable, we _have_ to do those conflicting changes in\norder to keep the pace of development. Its just about reporting them\nsanely and quickly which is ok to be done manually, but it pains me\nthat the info can be available with some tool as well with obvious\nbenifits of automation.\n\nSo the idea is sort of local linux-next style automation for small teams.\n\nBAIN\n\n> John\n"},{"id":"121988","messageId":"47ECFDB7-4189-4573-BC27-685603780F27@hoskings.net","threadId":"20769","inReplyTo":"2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Ben Hoskings","fromEmail":"ben@hoskings.net","sentAt":"2009-08-28T10:06:24Z","receivedAt":"2009-08-28T10:06:24Z","isPatch":false,"sender":{"key":"ben@hoskings.net","avatar":"https://gravatar.com/avatar/60ea3deb2865e547491ebef040a31093bb940fe1556da3bd1540a56bae2ca5a5?d=mp&s=160"},"body":"On 28/08/2009, at 5:02 PM, Abhijit Bhopatkar wrote:\n\n> I plan to do this on LAN using bonjour service discovery, and rest\n> completely being handled inside teamGIT running as a daemon(may be in\n> widely abused systray?). (Git will handle actual fetch/conflict\n> checking etc.)\n> On a side note i also plan to generate daily reports and configurable\n> notifications.\n>\n> So I ask you people, is there a solution already cooking someplace?\n> may be something i can integrate with teamGIT? (e.g. bonjour plugin\n> for git dameon)\n\nYou should check out bananajour, it sounds like it might fight the \nbill quite nicely:\n\nhttp://github.com/toolmantim/bananajour\n\nWritten by Tim Lucas, and hacked on by a bunch of us at the Gold \nCoast, Australia Railscamp in May:\nhttp://railscamps.com/\n\nThe idea is that for each repo you want to publish, bananajour creates \nand looks after a locally stored remote, that you push to (\"git push \nbanana master\") to publish your work over bonjour.\n\nThere's also a web interface at your-machine.local:9331 which shows \nthe other bananas that were found (via bonjour) on the network. \n['9331' is for 'peel' :) ]\n\nI'm not sure what the state of Linux support is, since most of us run \nOS X, but I'm pretty sure someone was working on Linux/zeroconf support.\n\nCheers\nBen Hoskings\n"},{"id":"121990","messageId":"52293B6C-5DE0-4BF4-8A4A-C1C44DD2AA82@hoskings.net","threadId":"20769","inReplyTo":"47ECFDB7-4189-4573-BC27-685603780F27@hoskings.net","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Ben Hoskings","fromEmail":"ben@hoskings.net","sentAt":"2009-08-28T10:17:37Z","receivedAt":"2009-08-28T10:17:37Z","isPatch":false,"sender":{"key":"ben@hoskings.net","avatar":"https://gravatar.com/avatar/60ea3deb2865e547491ebef040a31093bb940fe1556da3bd1540a56bae2ca5a5?d=mp&s=160"},"body":"On 28/08/2009, at 8:06 PM, Ben Hoskings wrote:\n\n> You should check out bananajour, it sounds like it might fight the \n> bill quite nicely:\n\nI mean, _fit_ the bill. My fingers got stuck in the '*ight' rhythm, I \nguess. :)\n\nBen\n"},{"id":"121991","messageId":"m3skfckzk1.fsf@localhost.localdomain","threadId":"20769","inReplyTo":"2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-28T10:22:58Z","receivedAt":"2009-08-28T10:22:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Abhijit Bhopatkar writes:\n\n> So I ask you people, is there a solution already cooking someplace?\n> may be something i can integrate with teamGIT? (e.g. bonjour plugin\n> for git dameon)\n\nThere is gitjour:\n http://rubyforge.org/projects/gitjour\n http://github.com/chad/gitjour\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"121999","messageId":"2fcfa6df0908280607h56c7af68x7b2e7ca78173c70a@mail.gmail.com","threadId":"20769","inReplyTo":"m3skfckzk1.fsf@localhost.localdomain","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Abhijit Bhopatkar","fromEmail":"bain@devslashzero.com","sentAt":"2009-08-28T13:07:46Z","receivedAt":"2009-08-28T13:07:46Z","isPatch":false,"sender":{"key":"bain@devslashzero.com","avatar":"https://gravatar.com/avatar/3f9bfde580be8d4de9df5a129387d9069d43eb1a65d745c583de9dfe9d97ebc8?d=mp&s=160"},"body":"2009/8/28 Jakub Narebski :\n> Abhijit Bhopatkar writes:\n>\n>> So I ask you people, is there a solution already cooking someplace?\n>> may be something i can integrate with teamGIT? (e.g. bonjour plugin\n>> for git dameon)\n>\n> There is gitjour:\n>  http://rubyforge.org/projects/gitjour\n>  http://github.com/chad/gitjour\n\nHmm... almost perfect, except i don't want to depend on ruby to be\ninstalled on the target machine.\nSigh!\n\nBAIN\n"},{"id":"127987","messageId":"20091120090529.GM17748@machine.or.cz","threadId":"20769","inReplyTo":"2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-20T09:05:30Z","receivedAt":"2009-11-20T09:05:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi!\n\nOn Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:\n> I plan to do this on LAN using bonjour service discovery\n\nI wonder why so much emphasis for this? It seems like a nifty\nconvenience bit, but I don't think making this idea too central is any\ngood. What if you get a second office at the other end of the world?\nWhat if part of your team is working on a deployment at customer site?\nWhat if part of your team works from home over a VPN? What if your\nteam is collaborating over the internet on an open project? What if...?\n\nThat said, it sounds like a great idea to have let's say a post-commit\nhook that will start an upload job:\n\n\textbranch=\"$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')\"\n\tpushurl=\"$(melting_pot)\"\n\tgit push --force \"$pushurl\" \"HEAD:$extbranch\" >/dev/null &\n\n(untested, +corner cases). On the server side, cronjob or post-update\nhook can do the integration testing. The complete setup should be\na matter of few-minutes hack.\n\nNow, it seems totally irrelevant if melting_pot is\n\n\tmelting_pot() { git config teamgit.meltingpot }\n\nor extra code that tries/caches some local discovery first.\n\n\nP.S.: It's not clear if you want the information sharing with commit\ngranularity or less - in that case, things might get rather tricky e.g.\nif you add new files and don't git add them until right before you\ncommit, and the work tree state might be total mess anyway.\n\nP.P.S.: It's not clear if you strive after complete de-centralization of\nthe service, with no central melting pot. That would seem fancy, but\nI think rather useless and hard in practice to arrange your reports\nthat you want, etc. It's not clear again then if the integration testing\nshould happen on single machine they all vote on (samba-like), or if\nall machines should do integration-testing, and whether of all branches\nor only some of them, and how to recognize the interesting branches, and\nthings are getting very hairy already... Your requirements are too\nambiguous.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"},{"id":"127988","messageId":"20091120091209.GN17748@machine.or.cz","threadId":"20769","inReplyTo":"20091120090529.GM17748@machine.or.cz","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2009-11-20T09:12:09Z","receivedAt":"2009-11-20T09:12:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 20, 2009 at 10:05:30AM +0100, Petr Baudis wrote:\n> Hi!\n> \n> On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:\n> > I plan to do this on LAN using bonjour service discovery\n> \n> I wonder why so much emphasis for this? It seems like a nifty\n> convenience bit, but I don't think making this idea too central is any\n> good. What if you get a second office at the other end of the world?\n> What if part of your team is working on a deployment at customer site?\n> What if part of your team works from home over a VPN? What if your\n> team is collaborating over the internet on an open project? What if...?\n> \n> That said, it sounds like a great idea to have let's say a post-commit\n> hook that will start an upload job:\n> \n> \textbranch=\"$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')\"\n\nThanks to sitaram, now I know that probably the best way is:\n\n \textbranch=\"$(whoami)/$(git describe --contains --all HEAD)\"\n\t\n(But now you *really* need to check if HEAD is a heads ref first or you\nwill push out to something totally bogus.)\n\nP.S.: Heh, I would never guess what that git describe command already\ndoes, talk about intuitiveness. ;-) (Of course, when you know exactly\nwhat the switches do, it totally makes sense.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"},{"id":"127991","messageId":"20091120094932.GA3528@atjola.homenet","threadId":"20769","inReplyTo":"20091120091209.GN17748@machine.or.cz","subject":"Re: [RFC] teamGIT bonjour support","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-11-20T09:49:32Z","receivedAt":"2009-11-20T09:49:32Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.11.20 10:12:09 +0100, Petr Baudis wrote:\n> On Fri, Nov 20, 2009 at 10:05:30AM +0100, Petr Baudis wrote:\n> > Hi!\n> > \n> > On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:\n> > > I plan to do this on LAN using bonjour service discovery\n> > \n> > I wonder why so much emphasis for this? It seems like a nifty\n> > convenience bit, but I don't think making this idea too central is any\n> > good. What if you get a second office at the other end of the world?\n> > What if part of your team is working on a deployment at customer site?\n> > What if part of your team works from home over a VPN? What if your\n> > team is collaborating over the internet on an open project? What if...?\n> > \n> > That said, it sounds like a great idea to have let's say a post-commit\n> > hook that will start an upload job:\n> > \n> > \textbranch=\"$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')\"\n> \n> Thanks to sitaram, now I know that probably the best way is:\n> \n> \textbranch=\"$(whoami)/$(git describe --contains --all HEAD)\"\n> \t\n> (But now you *really* need to check if HEAD is a heads ref first or you\n> will push out to something totally bogus.)\n\nHm, I'd go for:\n$(whoami)/$(git rev-parse --symbolic-full-name HEAD | sed s,refs/heads/,,)\n\ngives the shortname of the checked out branch head, or HEAD when you're\non a detached HEAD.\n\nBjoern ;-)\n"}]}