git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rainux <rainux@gmail.com>
To: git@vger.kernel.org
Subject: Which is the better repository structure for my project?
Date: Wed, 27 Aug 2008 17:54:27 +0800	[thread overview]
Message-ID: <a7f79a680808270254u6900bbf9o453fa741cca069ad@mail.gmail.com> (raw)

I have a web application ProjectFoo managed by subversion, and now I
want to use git to manage it.

ProjectFoo have
* 4 editions, the differences between each edition are trivial things
just like images & CSS files.
* 2 development lines, stable & unstable, so we can always do bug
fixing in latest stable branches, and add new features to unstable
branches, test them and finally deploy them as new stable branches
like 1.2.

The repository structure of project_foo looks like this:

|
+- trunk
|
+- branches -+- stable -+- 1.0 -+- trunk
             |          |       |
             |          |       +- edition_1
             |          |       |
             |          |       +- edition_2
             |          |
             |          +- 1.1 -+- trunk
             |                  |
             |                  +- edition_1
             |                  |
             |                  +- edition_2
             |
             +- unstable -+- edition_1
                          |
                          +- edition_2

I've found git-svnconvert.rb can convert subversion repository which
have strange branches structure like above to git repository, and I've
done some modifications & fixing to make it works with the latest
version of git. It even can split a subversion repository to several
git repositories by branch.

I've imagined 2 different structures of the new repository:
1. Follow the old structure of subversion repository. The known down
side is, with single git repository, I can not test 4 editions at the
same time.
2. Split to several repositories by edition, each repository contain 2
branches (stable & unstable) of an edition, and a repository of
"trunk" edition used to do the main development, other edition of
repository just track "trunk" repository and pull changes from it.

Which one is better?

I've tested method 2, when do git pull on edition_1 repository, it
seems do not known which changes already made on edition_1, and looks
like try to merge all changes on trunk/master (from "trunk"
repository) to edition_1/master, actually these changes already merged
to edition_1 in subversion repository.

The question is, when repo_1 start to remote tracking repo_2, is there
any method to tell git that repo_1 is "already up-to-date" with
repo_2, so that git pull will just merge new changes on repo_2 to
repo_1?


-- 
Best Regards

Rainux

                 reply	other threads:[~2008-08-27  9:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a7f79a680808270254u6900bbf9o453fa741cca069ad@mail.gmail.com \
    --to=rainux@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).