{"thread":{"id":"15216","subject":"Which is the better repository structure for my project?","startedAt":"2008-08-27T09:54:27Z","lastAt":"2008-08-27T09:54:27Z","messageCount":1,"participants":["Rainux"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88717","messageId":"a7f79a680808270254u6900bbf9o453fa741cca069ad@mail.gmail.com","threadId":"15216","inReplyTo":null,"subject":"Which is the better repository structure for my project?","fromName":"Rainux","fromEmail":"rainux@gmail.com","sentAt":"2008-08-27T09:54:27Z","receivedAt":"2008-08-27T09:54:27Z","isPatch":false,"sender":{"key":"rainux@gmail.com","avatar":null},"body":"I have a web application ProjectFoo managed by subversion, and now I\nwant to use git to manage it.\n\nProjectFoo have\n* 4 editions, the differences between each edition are trivial things\njust like images & CSS files.\n* 2 development lines, stable & unstable, so we can always do bug\nfixing in latest stable branches, and add new features to unstable\nbranches, test them and finally deploy them as new stable branches\nlike 1.2.\n\nThe repository structure of project_foo looks like this:\n\n|\n+- trunk\n|\n+- branches -+- stable -+- 1.0 -+- trunk\n             |          |       |\n             |          |       +- edition_1\n             |          |       |\n             |          |       +- edition_2\n             |          |\n             |          +- 1.1 -+- trunk\n             |                  |\n             |                  +- edition_1\n             |                  |\n             |                  +- edition_2\n             |\n             +- unstable -+- edition_1\n                          |\n                          +- edition_2\n\nI've found git-svnconvert.rb can convert subversion repository which\nhave strange branches structure like above to git repository, and I've\ndone some modifications & fixing to make it works with the latest\nversion of git. It even can split a subversion repository to several\ngit repositories by branch.\n\nI've imagined 2 different structures of the new repository:\n1. Follow the old structure of subversion repository. The known down\nside is, with single git repository, I can not test 4 editions at the\nsame time.\n2. Split to several repositories by edition, each repository contain 2\nbranches (stable & unstable) of an edition, and a repository of\n\"trunk\" edition used to do the main development, other edition of\nrepository just track \"trunk\" repository and pull changes from it.\n\nWhich one is better?\n\nI've tested method 2, when do git pull on edition_1 repository, it\nseems do not known which changes already made on edition_1, and looks\nlike try to merge all changes on trunk/master (from \"trunk\"\nrepository) to edition_1/master, actually these changes already merged\nto edition_1 in subversion repository.\n\nThe question is, when repo_1 start to remote tracking repo_2, is there\nany method to tell git that repo_1 is \"already up-to-date\" with\nrepo_2, so that git pull will just merge new changes on repo_2 to\nrepo_1?\n\n\n-- \nBest Regards\n\nRainux\n"}]}