{"thread":{"id":"33408","subject":"Advice and repo setup","startedAt":"2013-04-06T17:51:20Z","lastAt":"2013-04-10T17:59:04Z","messageCount":4,"participants":["Michael Campbell","Seth Robertson","Thomas Koch","Jakub Narębski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"213358","messageId":"CAKtB=OAot3y8fMjAf+Vh-=wOeX5b=F_N6_BLjK0fhGxGCg3Txg@mail.gmail.com","threadId":"33408","inReplyTo":null,"subject":"Advice and repo setup","fromName":"Michael Campbell","fromEmail":"michael.campbell@gmail.com","sentAt":"2013-04-06T17:51:20Z","receivedAt":"2013-04-06T17:51:20Z","isPatch":false,"sender":{"key":"michael.campbell@gmail.com","avatar":null},"body":"My company is moving from CVS to git in a few weeks (and we have a\ntraining class scheduled with the github folks).\n\nThat said our CI/build guys have already got gitorious set up (we get\nto it through ssh with ssh keys and one \"git\" user on the server) and\nwe are in the process of migrating all new CVS checkins to a git repo.\n\nAs a business decision we have decided to pull in some \"staff\naugmentation\".  We don't want the remote developers to have direct\naccess.  Our plan is to have some sort of external repo on which they\ncan push things, and locally we can pull those changes to our\n\"official\" repo and check it as we go.  So far so good.\n\nOur product has several logically separate projects, which right now\nwe have in the one big mega repo (in CVS, and migrating per checkin to\nGitorious).\n\nSo... I was wondering what the best way to split up our new repo might\nbe - or is it best to NOT split it?   One of the concerns we have is\nthat in the one big repo we can't control access to the various\nprojects.  So far we haven't needed to but this might be because we\ncouldn't.\n\nSo one plan is to have multiple repos, and then a mirror of those for\nthe remote devs.  The other plan is to say \"sod it\" and have one local\nand one remote and just suffer through possible non-requirements of\nvarying authorization profiles.\n\nIs there documentation I can refer to for this, or is there an obvious\nway to do these things?  Any help or pointers appreciated.\n"},{"id":"213359","messageId":"201304061809.r36I9YZp031127@no.baka.org","threadId":"33408","inReplyTo":"CAKtB=OAot3y8fMjAf+Vh-=wOeX5b=F_N6_BLjK0fhGxGCg3Txg@mail.gmail.com","subject":"Re: Advice and repo setup","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2013-04-06T18:09:34Z","receivedAt":"2013-04-06T18:09:34Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message <CAKtB=OAot3y8fMjAf+Vh-=wOeX5b=F_N6_BLjK0fhGxGCg3Txg@mail.gmail.com>, Michael Campbell writes:\n\n    As a business decision we have decided to pull in some \"staff\n    augmentation\".  We don't want the remote developers to have direct\n    access.  Our plan is to have some sort of external repo on which they\n    can push things, and locally we can pull those changes to our\n    \"official\" repo and check it as we go.  So far so good.\n\nYou might want to consider using something like gitolite where you can\nhave control over which branches users can write to.  Assuming you are\nnot trying to restrict some branches of some repos from the external\nusers, this would be a better solution than setting up another repo\nwith some kind of automatic mirroring scheme, though that of course\nwill also work.\n\n    Our product has several logically separate projects, which right now\n    we have in the one big mega repo (in CVS, and migrating per checkin to\n    Gitorious).\n\nCertainly I'd recommend using one repo per conceptual unit.  There are\nseveral techniques to group repos together if you need to.\n\n    Is there documentation I can refer to for this, or is there an obvious\n    way to do these things?  Any help or pointers appreciated.\n\nhttp://sethrobertson.github.com/GitBestPractices/\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"213376","messageId":"201304070812.18797.thomas@koch.ro","threadId":"33408","inReplyTo":"CAKtB=OAot3y8fMjAf+Vh-=wOeX5b=F_N6_BLjK0fhGxGCg3Txg@mail.gmail.com","subject":"Re: Advice and repo setup","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2013-04-07T06:12:15Z","receivedAt":"2013-04-07T06:12:15Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"Michael Campbell:\n> So one plan is to have multiple repos, and then a mirror of those for\n> the remote devs.  The other plan is to say \"sod it\" and have one local\n> and one remote and just suffer through possible non-requirements of\n> varying authorization profiles.\n\nYou could also use Gerrit[1]. It's not only a code review server (and any team \nshould have code review). It also hosts git repositories and you can write \nsubmit rules to reflect any possible write rule your company might have[2].\n\n[1] http://en.wikipedia.org/wiki/Gerrit_%28software%29\n[2] https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html\n\nRegards,\n\nThomas Koch, http://www.koch.ro\n"},{"id":"213792","messageId":"5165A868.2020801@gmail.com","threadId":"33408","inReplyTo":"CAKtB=OAot3y8fMjAf+Vh-=wOeX5b=F_N6_BLjK0fhGxGCg3Txg@mail.gmail.com","subject":"Re: Advice and repo setup","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2013-04-10T17:59:04Z","receivedAt":"2013-04-10T17:59:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael Campbell wrote:\n\n> My company is moving from CVS to git in a few weeks (and we have a\n> training class scheduled with the github folks).\n> \n> That said our CI/build guys have already got gitorious set up (we get\n> to it through ssh with ssh keys and one \"git\" user on the server)\n\nNote that gitorious is git hosting software / software forge, i.e.\ncombination of git hosting [configuration] software, web interface\nto repositories, and web-based administration.\n\nThis is not the only solution.  Among other all-in-one solutions\nare GitHUb:FI / GitHub Enterprise (proprietary and costly), InDefero,\nGitLab, Girocco + gitweb (what repo.or.cz uses).  There are also pure\nweb interfaces, and there are pure repository management software\nlike gitosis (possibly unmaintained) and gitolite.\n\nI see GitHub Enterprise and GitLab both recommended as alternatives\nto Gitorious. But supposedly the most trouble is with installation,\nand you write that you \"have already got gitorious set up\".\n\nUnfortunately the Git Tools wiki page is not very actively maintained:\nhttps://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n\n> and\n> we are in the process of migrating all new CVS checkins to a git repo.\n\nWhat tool do you use for that?  Do you have tool selected to perform\na full migration from CVS to Git (to have full history in Git), or\nwill you cut off the history (perhaps stitching it later with historical\nrepo with history imported from CVS, via grafts or git-replace), like\nLinux kernel did when moving from BitKeeper to Git?\n\nBTW. it might make sense if you have time to massage the history\nimported from CVS to remove CVS-related crufts and mishaps, e.g. with\nthe reposurgeon tool (http://www.catb.org/esr/reposurgeon/)\n\n> As a business decision we have decided to pull in some \"staff\n> augmentation\".  We don't want the remote developers to have direct\n> access.  Our plan is to have some sort of external repo on which they\n> can push things, and locally we can pull those changes to our\n> \"official\" repo and check it as we go.  So far so good.\n\nAnother possible workflow is to have each of remote developers to get\nupdates from central \"blessed\" official repository, but for each to have\ntheir own publishing repository they push to (and send pull requests about).\n\nOr maybe something hierarchical, with each group having their own\nrepository...\n\n> Our product has several logically separate projects, which right now\n> we have in the one big mega repo (in CVS, and migrating per checkin to\n> Gitorious).\n\nErrr... didn't you use so called \"modules\" in CVS?  Those usually\ntranslate to projects, which translate to git repositories.\n\n> So... I was wondering what the best way to split up our new repo might\n> be - or is it best to NOT split it?   One of the concerns we have is\n> that in the one big repo we can't control access to the various\n> projects.  So far we haven't needed to but this might be because we\n> couldn't.\n\nSplit it, of course, into individual independent (more or less) project\nrepositories.  Note for example that you can tag (give name to a\nrelease) only whole repository.\n\n> So one plan is to have multiple repos, and then a mirror of those for\n> the remote devs.  The other plan is to say \"sod it\" and have one local\n> and one remote and just suffer through possible non-requirements of\n> varying authorization profiles.\n\nIt would also lead to slower operations (git works well with large\nnumber of files, but not necessarily with very large number of files),\nand increased storage (you can clone only whole repository even if\nnowadays you can check out only part of it; and you want for each\ndeveloper to have their own private clone to work in).\n\n> Is there documentation I can refer to for this, or is there an obvious\n> way to do these things?  Any help or pointers appreciated.\n\n-- \nJakub Narębski\n"}]}