{"thread":{"id":"18356","subject":"Suggested Workflow Question","startedAt":"2009-03-17T17:51:10Z","lastAt":"2009-04-17T21:11:24Z","messageCount":7,"participants":["Roger Garvin","Marcel M. Cary","Martin Langhoff","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108267","messageId":"loom.20090317T175010-470@post.gmane.org","threadId":"18356","inReplyTo":null,"subject":"Suggested Workflow Question","fromName":"Roger Garvin","fromEmail":"yoyodyn@gmail.com","sentAt":"2009-03-17T17:51:10Z","receivedAt":"2009-03-17T17:51:10Z","isPatch":false,"sender":{"key":"yoyodyn@gmail.com","avatar":null},"body":"I work for a small company with about 15 developers who work concurrently on\nabout 10+ projects both in new development and support.\nWe do custom software for manufacturing and production systems. Part of our\ncontracts with our customers is a perpetual single use license of the source\ncode at each facility.\nSo we have a copy of the source on our office server, and another copy at each\ncustomer site. When we had only 5 developers it was easier to handle. Now that\nwe are growing we need a source control system and I have been looking heavily\ninto Git. Our old workflow does not seem that it will fit well with Git\nhowever, but I feel that I need a distributed system to keep track of the office\nversion and the on-site versions of our source since development is taking place\non both.\n(Some customers also have separate development, and testing versions on their\nservers as well.)\n\nI have created git repositories on a couple of our project source directories as\ntest beds. Right now (second day) I am the only one who is actually using git.\n Everyone else is simply accessing the files on the server as they have always\ndone, and I am making the commits when I see signifigant changes. \n\nMy question is really a request for modified workflow ideas. My plan was to\nhave a master repository in our office server with clones at each customer site,\nand multiple branches for test, QA, and production versions of the source.\nSince most of these customers have closed networks, we would rely on people\ntraveling onsite, or emailing patches to get any updates back into our office\nrepository. \n\nThank you for any assistance for this revision control newb.\n\nRoger Garvin\n"},{"id":"108307","messageId":"49C04DFC.10201@earth.care2.com","threadId":"18356","inReplyTo":"loom.20090317T175010-470@post.gmane.org","subject":"Re: Suggested Workflow Question","fromName":"Marcel M. Cary","fromEmail":"marcel@earth.care2.com","sentAt":"2009-03-18T01:27:24Z","receivedAt":"2009-03-18T01:27:24Z","isPatch":false,"sender":{"key":"marcel@earth.care2.com","avatar":null},"body":"Roger Garvin wrote:\n> I work for a small company with about 15 developers who work concurrently on\n> about 10+ projects both in new development and support.\n> We do custom software for manufacturing and production systems. Part of our\n> contracts with our customers is a perpetual single use license of the source\n> code at each facility.\n> So we have a copy of the source on our office server, and another copy at each\n> customer site. When we had only 5 developers it was easier to handle. Now that\n> we are growing we need a source control system and I have been looking heavily\n> into Git. Our old workflow does not seem that it will fit well with Git\n> however, but I feel that I need a distributed system to keep track of the office\n> version and the on-site versions of our source since development is taking place\n> on both.\n> (Some customers also have separate development, and testing versions on their\n> servers as well.)\n> \n> I have created git repositories on a couple of our project source directories as\n> test beds. Right now (second day) I am the only one who is actually using git.\n> Everyone else is simply accessing the files on the server as they have always\n> done, and I am making the commits when I see signifigant changes.\n> \n> My question is really a request for modified workflow ideas. My plan was to\n> have a master repository in our office server with clones at each customer site,\n> and multiple branches for test, QA, and production versions of the source.\n> Since most of these customers have closed networks, we would rely on people\n> traveling onsite, or emailing patches to get any updates back into our office\n> repository.\n> \n> Thank you for any assistance for this revision control newb.\n> \n> Roger Garvin\n\nThe workflow elements you mention so far sound sane to me:\n\n* a repository in your office\n* repositories at customer sites\n* emailing patches when direct connections are not possible\n* test and dev branches for each customer\n\nI presume there will also be a production branch in customer \nrepositories on which you arrange production releases... or maybe you \njust tag your test branch when it passes?\n\nWhen you send patches via email, keep in mind that you'll have to convey \nwhich branch they belong on \"out of band\", for example after the commit \nmessage and above the diffstat.\n\nThere was an interesting discussion about maintaining per-client code on \ndifferent branches recently, but I can't find it.\n\nI've found Git to be very flexible. Maybe you could start by emulating \nyour current workflow and refine it as you go? If you find you don't \nknow how code travels currently... well, maybe you can just let your \nteam pass patches around until patterns emerge.\n\nMarcel\n"},{"id":"108327","messageId":"49C07077.9020904@earth.care2.com","threadId":"18356","inReplyTo":"49C04DFC.10201@earth.care2.com","subject":"Re: Suggested Workflow Question","fromName":"Marcel M. Cary","fromEmail":"marcel@earth.care2.com","sentAt":"2009-03-18T03:54:31Z","receivedAt":"2009-03-18T03:54:31Z","isPatch":false,"sender":{"key":"marcel@earth.care2.com","avatar":null},"body":"Marcel Cary wrote:\n> Roger Garvin wrote:\n>> So we have a copy of the source on our office server, and another copy at each\n>> customer site.\n\n>> (Some customers also have separate development, and testing versions on their\n>> servers as well.)\n\n> There was an interesting discussion about maintaining per-client code on\n> different branches recently, but I can't find it.\n\nHere's the broader thread:\nhttp://thread.gmane.org/gmane.comp.version-control.git/113278\n\nThis is an abridged summary:\nhttp://article.gmane.org/gmane.comp.version-control.git/110697\n\nAnd this a nice explanation referenced by the summary:\nhttp://gitster.livejournal.com/26540.html\n\nMarcel\n"},{"id":"108330","messageId":"46a038f90903172141o7b272c17v2c485bb66b529fe8@mail.gmail.com","threadId":"18356","inReplyTo":"49C04DFC.10201@earth.care2.com","subject":"Re: Suggested Workflow Question","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2009-03-18T04:41:50Z","receivedAt":"2009-03-18T04:41:50Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Wed, Mar 18, 2009 at 2:27 PM, Marcel M. Cary wrote:\n> * emailing patches when direct connections are not possible\n> * test and dev branches for each customer\n\nWe've done a ton of that. Even better than emailing is that you can\nhave a repo on a usb stick/disk.\n\n - At the office, update it from the 'office' repository.\n - At the client site, pull updates from the usb stick, and push any\ncode developed at teh client side to the stick\n - Back at the office, push to the office repo\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"108369","messageId":"loom.20090318T125717-946@post.gmane.org","threadId":"18356","inReplyTo":"46a038f90903172141o7b272c17v2c485bb66b529fe8@mail.gmail.com","subject":"Re: Suggested Workflow Question","fromName":"Roger Garvin","fromEmail":"yoyodyn@gmail.com","sentAt":"2009-03-18T13:00:51Z","receivedAt":"2009-03-18T13:00:51Z","isPatch":false,"sender":{"key":"yoyodyn@gmail.com","avatar":null},"body":"Martin Langhoff gmail.com> writes:\n\n> We've done a ton of that. Even better than emailing is that you can\n> have a repo on a usb stick/disk.\n> \n\nThat would be great except that most of our customers do not technically allow\nus to plug USB drives into any of their computers. It's a rather silly rule\nactually but the drives could be confiscated. \n\nThank you for the links to the other thread. I will read through those today.\nI am hoping that this is simpler in practice than it looks on paper, cause what\nI see on paper is a fully connected graph of all our employees with all our\ncustomers multiple source locations and with our office server. It seems like\nit could get out of control for tracking where changes might be (who is holding\nthem)\n\n\nRoger Garvin\n"},{"id":"108371","messageId":"200903181452.53497.robin.rosenberg.lists@dewire.com","threadId":"18356","inReplyTo":"loom.20090318T125717-946@post.gmane.org","subject":"Re: Suggested Workflow Question","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-03-18T13:52:53Z","receivedAt":"2009-03-18T13:52:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 18 mars 2009 14:00:51 skrev Roger Garvin :\n> Martin Langhoff gmail.com> writes:\n> \n> > We've done a ton of that. Even better than emailing is that you can\n> > have a repo on a usb stick/disk.\n> > \n> \n> That would be great except that most of our customers do not technically allow\n> us to plug USB drives into any of their computers. It's a rather silly rule\n> actually but the drives could be confiscated. \n> \n> Thank you for the links to the other thread. I will read through those today.\n> I am hoping that this is simpler in practice than it looks on paper, cause what\n> I see on paper is a fully connected graph of all our employees with all our\n> customers multiple source locations and with our office server. It seems like\n> it could get out of control for tracking where changes might be (who is holding\n> them)\n\nDon't forget the option of mailing bundles (man git-bundle). Those will give the effect of push/fetch via e-mail. I.e. the exact same commit SHA's get replicated, That may be relevant for the branches that contain your released/official test code.\n\n-- robin\n"},{"id":"111537","messageId":"loom.20090417T205632-412@post.gmane.org","threadId":"18356","inReplyTo":"200903181452.53497.robin.rosenberg.lists@dewire.com","subject":"Re: Suggested Workflow Question","fromName":"Roger Garvin","fromEmail":"yoyodyn@gmail.com","sentAt":"2009-04-17T21:11:24Z","receivedAt":"2009-04-17T21:11:24Z","isPatch":false,"sender":{"key":"yoyodyn@gmail.com","avatar":null},"body":"Robin Rosenberg dewire.com> writes:\n\n> Don't forget the option of mailing bundles (man git-bundle). Those will give\nthe effect of push/fetch via\n> e-mail. I.e. the exact same commit SHA's get replicated, That may be relevant\nfor the branches that\n> contain your released/official test code.\n\nAfter trying this out for a little while I and projecting some into the future I\nthink I am going to have a problem that I am not sure if it really is a problem,\nor if Git will \"take care of it\". Let me give you a simplistic commit history\nto illustrate my point. In its most basic form you have three branches; dev,\ntest, prod. In a perfect world all the development happens on dev, then updates\nare pushed to test, and finally after tests pass are pushed out to prod. So at\na point in time you have something like this:\n\n(P)<--(T)<--(D)\n\nSince I would think (and maybe this is my problem) that ideally Prod is a direct\ndescendant of Test and Test is a direct descendant of Dev. However we don't\nlive in a perfect world, so changes get made on Test that aren't in production\nyet, and also in an emergency directly on the Prod branch. Eventually those\nchanges get migrated back either through a merge or a rebase (rebase would be\nbad since there would be multiple developers using these repos.) Obviously\nmaking a change to Prod and then merging back to Test, and then merging back to\nDev creates a lot of extra commits.\n\n (P)<---(T)<----(D)\n ^ ^ ^\n \\ \\ \\\n (P')<--(T')<--(D')\n\nThings get even more complicated when the customer decides to only push certain\nfeatures into Prod from test, it looks like cherry pick would be ideal for this\nand make it much easier for us.\n\nIs trying to maintain a direct ancestral relationship between Prod, Test, and\nDev worth it? Am I crazy for even trying to? I am still a pretty green git\nuser so it might not be worth it. But it does seem to me that merges might be\neasier and faster if the common ancestor between two commits is closer rather\nthan farther away in the commit history.\n\nThanks again for your help.\n"}]}