{"thread":{"id":"32281","subject":"Git repository and Maven project","startedAt":"2012-12-06T21:00:14Z","lastAt":"2012-12-06T21:35:20Z","messageCount":2,"participants":["Aleks","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204564","messageId":"50C1075E.1060407@gmail.com","threadId":"32281","inReplyTo":null,"subject":"Git repository and Maven project","fromName":"Aleks","fromEmail":"oles.slosko@gmail.com","sentAt":"2012-12-06T21:00:14Z","receivedAt":"2012-12-06T21:00:14Z","isPatch":false,"sender":{"key":"oles.slosko@gmail.com","avatar":null},"body":"Can you help to clarify such question.\nWe have 2 different projects.\nName of first project say \"server\".\nSecond - \"client\".\nEvery project has own maven build structure.\nServer produces the war archive for deployment.\nThe Client project produces the client jar for testing Server application.\nAside from these projects we should store different artefacts like \nprototypes for developing pages for server project.\nThere are two opinions about approach to arrangement git repository.\n\n1) Create one repository https://git.org/my-project/src\nCreate 3 separate folders inside of src directory. So we will have such \nstructure :\nroot of repository https://git.org/my-project/src/\ncontains 2 different maven projects and folder for prototypes files\nhttps://git.org/my-project/src/server\nhttps://git.org/my-project/src/client\nhttps://git.org/my-project/src/prototypes\n\n2)Create for every maven project and prototypes separate repository.\nhttps://git.org/my-server/src\nhttps://git.org/my-client/src\nhttps://git.org/prototypes/src\n\nThe root of maven project begins from src folder in every repository ( \nhttps://git.org/my-server/src and https://git.org/my-client/src)\nThe xml files and images of prototypes will be inside of \nhttps://git.org/prototypes/src\nI believe the second approach more proper git-approach.\nSuch approach allows team to use such advanced git features like \nbranging, merging, stash etc.\n\nWhat approach is proper?\n\n\n-- \n\nBest regards\nAleks\n"},{"id":"204565","messageId":"7vzk1qj23r.fsf@alter.siamese.dyndns.org","threadId":"32281","inReplyTo":"50C1075E.1060407@gmail.com","subject":"Re: Git repository and Maven project","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-06T21:35:20Z","receivedAt":"2012-12-06T21:35:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aleks <oles.slosko@gmail.com> writes:\n\n> Can you help to clarify such question.\n> We have 2 different projects.\n> Name of first project say \"server\".\n> Second - \"client\".\n> Every project has own maven build structure.\n> Server produces the war archive for deployment.\n> The Client project produces the client jar for testing Server application.\n> Aside from these projects we should store different artefacts like\n> prototypes for developing pages for server project.\n\nIt depends on how tightly coupled the versions of these three\n\"potentially separate but could be combined\" pieces you would want\nto make.  Is a particular version of the \"server\" software meant to\nwork with any random version of \"prototypes\"?  Is a particular\nversion of the \"client\" software meant to be used to test any random\nversion of \"server\"?\n\nHaving all three in the same repository means you are guaranteed,\nand more importantly, your developers are *forced* to guarantee, a\ncheckout of a single commit will contain the state of these three\npieces that work well together.  A commit that changes only the\n\"server\" subtree portion, without updating the corresponding assets\nin \"prototypes\" hierarchy that are needed to support what was added\nto the \"server\" part, would break the entire system, and hopefully\nyour QA procedure can detect and reject it.\n\nHaving all three in separate repositories means your developers can\nbe more loose but it may lead to QA nightmare if a proper procedure\nis arranged around the entire process (which Git is only a small\npart of).\n\n> I believe the second approach more proper git-approach.\n> Such approach allows team to use such advanced git features like\n> branging, merging, stash etc.\n\nThere is no single \"more proper git-approach\"; it depends on your\nrequirements, which the above \"how tightly coupled?\" question is\nan example of.  Branching, merging, etc. are orthogonal and can and\nwill be useful regardless of the repository arrangement you choose.\n"}]}