From: Junio C Hamano <gitster@pobox.com>
To: Aleks <oles.slosko@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Git repository and Maven project
Date: Thu, 06 Dec 2012 13:35:20 -0800 [thread overview]
Message-ID: <7vzk1qj23r.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <50C1075E.1060407@gmail.com> (Aleks's message of "Thu, 06 Dec 2012 23:00:14 +0200")
Aleks <oles.slosko@gmail.com> writes:
> Can you help to clarify such question.
> We have 2 different projects.
> Name of first project say "server".
> Second - "client".
> Every project has own maven build structure.
> Server produces the war archive for deployment.
> The Client project produces the client jar for testing Server application.
> Aside from these projects we should store different artefacts like
> prototypes for developing pages for server project.
It depends on how tightly coupled the versions of these three
"potentially separate but could be combined" pieces you would want
to make. Is a particular version of the "server" software meant to
work with any random version of "prototypes"? Is a particular
version of the "client" software meant to be used to test any random
version of "server"?
Having all three in the same repository means you are guaranteed,
and more importantly, your developers are *forced* to guarantee, a
checkout of a single commit will contain the state of these three
pieces that work well together. A commit that changes only the
"server" subtree portion, without updating the corresponding assets
in "prototypes" hierarchy that are needed to support what was added
to the "server" part, would break the entire system, and hopefully
your QA procedure can detect and reject it.
Having all three in separate repositories means your developers can
be more loose but it may lead to QA nightmare if a proper procedure
is arranged around the entire process (which Git is only a small
part of).
> I believe the second approach more proper git-approach.
> Such approach allows team to use such advanced git features like
> branging, merging, stash etc.
There is no single "more proper git-approach"; it depends on your
requirements, which the above "how tightly coupled?" question is
an example of. Branching, merging, etc. are orthogonal and can and
will be useful regardless of the repository arrangement you choose.
prev parent reply other threads:[~2012-12-06 21:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-06 21:00 Git repository and Maven project Aleks
2012-12-06 21:35 ` Junio C Hamano [this message]
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=7vzk1qj23r.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=oles.slosko@gmail.com \
/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