{"thread":{"id":"4287","subject":"importing cvs logical modules","startedAt":"2006-05-25T04:48:25Z","lastAt":"2006-05-25T07:02:19Z","messageCount":7,"participants":["Geoff Russell","Jakub Narebski","Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20666","messageId":"93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com","threadId":"4287","inReplyTo":null,"subject":"importing cvs logical modules","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2006-05-25T04:48:25Z","receivedAt":"2006-05-25T04:48:25Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"Hi,\n\nFirstly, the code to automagically\nrepack a git repository on-the-fly during a big load has solved one of\nmy problems - thanks, it is great. Unfortunately  it has bought me to\nshowstopper number 2.\n\n- cvs modules.\n\ncvs allows you to define modules which rearrange the physical repository into\na different logical structure.  This sounds great and we use it, but it gives\nus other headaches because \"cvs update\" doesn't always do the right\nthing with these modules.\n\nFurthermore cvsps doesn't appear to handle this module feature at all and\nis tricked into thinking that rearranged directories come from somewhere\nelse and issues its \"file xxx doesn't match strip_path\" message.\n\nI have tried to hack cvsps to go around the problem, but without success.\n\nAnother alternative that I thought might be easier would be to unload the cvs\nrepository in clean pieces - each being a git repository. Then to join the\ngit repositories together in the desired way. I think this would be\ngenerally useful and not just solve my problem.\n\ne.g. Suppose I have 3 git repositories: Progs, xxxx, yyyy\n\n           Progs/.git\n           xxxx/.git\n           yyyy/.git\n\nI'd like to make 1 git repository Progs with xxxx and yyyy as child trees.\n\n           Progs/.git\n           Progs/xxxx\n           Progs/yyyy\n\nDoes this sound useful to anyone else, or is it already possible?\n\n\nCheers,\nGeoff Russell.\n"},{"id":"20668","messageId":"e53ddc$ol1$1@sea.gmane.org","threadId":"4287","inReplyTo":"93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com","subject":"Re: importing cvs logical modules","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-25T04:56:12Z","receivedAt":"2006-05-25T04:56:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Geoff Russell wrote:\n\n> Then to join the git repositories together in the desired way. I think\n> this would be generally useful and not just solve my problem.\n> \n> e.g. Suppose I have 3 git repositories: Progs, xxxx, yyyy\n> \n>            Progs/.git\n>            xxxx/.git\n>            yyyy/.git\n> \n> I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.\n> \n>            Progs/.git\n>            Progs/xxxx\n>            Progs/yyyy\n> \n> Does this sound useful to anyone else, or is it already possible?\n\nIt is done. TODO branch in git.git repository on kernel.org is pushed to\nfrom *separate* git-todo.git repository. BTW. working are of repositories\ncan be joined (although it needs entry in .gitignore):\n\n   Progs/.git\n   Progs/TODO/.git\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20669","messageId":"7vslmyzoit.fsf@assigned-by-dhcp.cox.net","threadId":"4287","inReplyTo":"93c3eada0605242148u4656bc31p96d84a16703f0fe0@mail.gmail.com","subject":"Re: importing cvs logical modules","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-25T05:01:14Z","receivedAt":"2006-05-25T05:01:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Geoff Russell\" <geoffrey.russell@gmail.com> writes:\n\n> I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.\n>\n>           Progs/.git\n>           Progs/xxxx\n>           Progs/yyyy\n>\n> Does this sound useful to anyone else, or is it already possible?\n\nI would do it like this:\n\n           Progs/.git\n           Progs/xxxx/.git\n           Progs/yyyy/.git\n\nI do not know what you have in Progs/ hierarchy -- if it is just\nscaffolding to house subdirectories and nothing else you may not\neven need Progs/.git repository.\n\nThis is a very useful and handy structure, and you do not need\nany tool support once you have these as separate repositories.\nIf you want a single distribution point, you can push from these\nseparate repositories into separate branches of a single\ndistribution point repository [*1*].\n\nOne potential disadvantage is that you would not get revision\nlinkage between these \"modules\", but not having tight linkage is\nthe point of modular structure, so depending on your workflow it\nprobably may not matter.\n\n\n[Footnote]\n\n*1* In fact, my git working area has the \"master\", \"next\" or\n\"pu\" branch checked out in /path/to/work/area/git (and the\nrepository is in /path/to/work/area/git/.git directory), and I\ncheck out the \"todo\" branch in /path/to/work/area/git/Meta\ndirectory, with /path/to/work/area/git/Meta/.git directory as\nits repository.\n"},{"id":"20672","messageId":"93c3eada0605242302x24ca1272xd7bfc3a677b32845@mail.gmail.com","threadId":"4287","inReplyTo":"7vslmyzoit.fsf@assigned-by-dhcp.cox.net","subject":"Re: importing cvs logical modules","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2006-05-25T06:02:55Z","receivedAt":"2006-05-25T06:02:55Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On 5/25/06, Junio C Hamano <junkio@cox.net> wrote:\n> \"Geoff Russell\" <geoffrey.russell@gmail.com> writes:\n>\n> > I'd like to make 1 git repository Progs with xxxx and yyyy as child trees.\n> >\n> >           Progs/.git\n> >           Progs/xxxx\n> >           Progs/yyyy\n> >\n> > Does this sound useful to anyone else, or is it already possible?\n>\n> I would do it like this:\n>\n>            Progs/.git\n>            Progs/xxxx/.git\n>            Progs/yyyy/.git\n>\n> I do not know what you have in Progs/ hierarchy -- if it is just\n> scaffolding to house subdirectories and nothing else you may not\n> even need Progs/.git repository.\n>\n> This is a very useful and handy structure, and you do not need\n> any tool support once you have these as separate repositories.\n> If you want a single distribution point, you can push from these\n> separate repositories into separate branches of a single\n> distribution point repository [*1*].\n>\n> One potential disadvantage is that you would not get revision\n> linkage between these \"modules\", but not having tight linkage is\n> the point of modular structure, so depending on your workflow it\n> probably may not matter.\n\nThe tight linkage is absolutely essential.\n\nWhen we tag the system, we\nwant to tag everything (not individually tag all 300 programs)\nso that later we can to branch at that tag. Very few of our\nprograms are self contained, they generally make heavy use\nof one or more libraries --- which must also be part of the\ntree. The full structure should end up looking like:\n\n        Top/.git\n        Libraries/libx\n        Libraries/liby\n        Libraries/boost\n        Libraries/...\n        Programs/xxx\n        Programs/yyy\n        Programs/...\n        ...etc.\n\nWhen we build a full system, we want to tag that point so\nwe can know exactly what went into that build.\n\nWe used to do it the \"other\" way.\n\n         cvsroot/xxx\n         cvsroot/yyy\n         cvsroot/liby\n         cvsroot/libx\n         etc\n\nBut then when we did a system build, someone always forgot\nto tag something. So we got cvs to build a build logical tree\nand then cvs was quite happy to tag the lot with one go and\nnothing got forgotten. So now we are trying to pull the\nlot into git as one big tree.\n\nCheers,\nGeoff.\n\n\n>\n>\n> [Footnote]\n>\n> *1* In fact, my git working area has the \"master\", \"next\" or\n> \"pu\" branch checked out in /path/to/work/area/git (and the\n> repository is in /path/to/work/area/git/.git directory), and I\n> check out the \"todo\" branch in /path/to/work/area/git/Meta\n> directory, with /path/to/work/area/git/Meta/.git directory as\n> its repository.\n>\n>\n"},{"id":"20673","messageId":"46a038f90605242316l4b0a0963m638f7a2e47936000@mail.gmail.com","threadId":"4287","inReplyTo":"93c3eada0605242302x24ca1272xd7bfc3a677b32845@mail.gmail.com","subject":"Re: importing cvs logical modules","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-05-25T06:16:47Z","receivedAt":"2006-05-25T06:16:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:\n> The tight linkage is absolutely essential.\n>\n> When we tag the system, we\n> want to tag everything (not individually tag all 300 programs)\n> so that later we can to branch at that tag. Very few of our\n\nThen you want a single git repo/tree/project. The thing is how to work\nthrough your mangled CVS history.\n\nTwo options there...\n\n - Don't. Import from after the last directory reorg or from your last\ninteresting release. Keep the cvs tree for people who really want to\ndig into the past. this has several advantages, as initial checkouts\nwill be faster, import times shorter, less pain overall.\n\n - Mangle import to match your reorganizations:\n   - Generate the cvsps output file\n   - Duplicate/copy files in the cvs repo so that files are in both\nplaces if you've been mving them around.\n   - Mangle the cvsps output file from each reorg onwards. This is\nnasty, but it will define the history that cvsimport sees.\n\ncheers,\n\n\nmartin\n"},{"id":"20675","messageId":"93c3eada0605242359k204bfe79vabc323eddfafa5f@mail.gmail.com","threadId":"4287","inReplyTo":"46a038f90605242316l4b0a0963m638f7a2e47936000@mail.gmail.com","subject":"Re: importing cvs logical modules","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2006-05-25T06:59:25Z","receivedAt":"2006-05-25T06:59:25Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:\n> On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:\n> > The tight linkage is absolutely essential.\n> >\n> > When we tag the system, we\n> > want to tag everything (not individually tag all 300 programs)\n> > so that later we can to branch at that tag. Very few of our\n>\n> Then you want a single git repo/tree/project. The thing is how to work\n> through your mangled CVS history.\n>\n> Two options there...\n>\n>  - Don't. Import from after the last directory reorg or from your last\n> interesting release. Keep the cvs tree for people who really want to\n> dig into the past. this has several advantages, as initial checkouts\n> will be faster, import times shorter, less pain overall.\n\nYes, this is definitely on the shortlist of options.\nIf we can't keep all the history, we may as well make\na clean start. Thanks for the advice.\n\nCheers,\nGeoff.\n"},{"id":"20676","messageId":"e53kpq$ddf$1@sea.gmane.org","threadId":"4287","inReplyTo":"93c3eada0605242359k204bfe79vabc323eddfafa5f@mail.gmail.com","subject":"Re: importing cvs logical modules","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-25T07:02:19Z","receivedAt":"2006-05-25T07:02:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Geoff Russell wrote:\n\n> On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:\n>> On 5/25/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:\n>>> The tight linkage is absolutely essential.\n>>>\n>>> When we tag the system, we\n>>> want to tag everything (not individually tag all 300 programs)\n>>> so that later we can to branch at that tag. Very few of our\n>>\n>> Then you want a single git repo/tree/project. The thing is how to work\n>> through your mangled CVS history.\n>>\n>> Two options there...\n>>\n>>  - Don't. Import from after the last directory reorg or from your last\n>> interesting release. Keep the cvs tree for people who really want to\n>> dig into the past. this has several advantages, as initial checkouts\n>> will be faster, import times shorter, less pain overall.\n> \n> Yes, this is definitely on the shortlist of options.\n> If we can't keep all the history, we may as well make\n> a clean start. Thanks for the advice.\n\nWell, you can always copy history and graft old CVS history later. Perhaps\nwhen \"bind\" (or Cogito \"bind lite\") mature enough...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"}]}