From: "R. Tyler Ballance" <tyler@slide.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Managing submodules on large multi-user projects
Date: Fri, 29 May 2009 13:09:29 -0700 [thread overview]
Message-ID: <20090529200928.GH11222@starfruit.corp.slide.com> (raw)
In-Reply-To: <32541b130905291253k3fa1d675yde1dddb5e8090ef9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
On Fri, May 29, 2009 at 03:53:26PM -0400, Avery Pennarun wrote:
> On Fri, May 29, 2009 at 2:41 PM, R. Tyler Ballance <tyler@slide.com> wrote:
> > As some of you may recall from my last swath of emails to the list
> > regarding memory usage and repository size, we have quite a large
> > repository. About a month ago, I added a submodule to the primary repo
> > in an effort to start to segment where possible, particularly around
> > third party modules.
> >
> > I've noticed that keeping submodules updated is an absolute pain,
> > particularly with a large multiuser setup with *lots* of branches.
>
> Just so I understand, is the reason you're splitting into submodules
> *just* to avoid memory usage / repository size issues? I can sort of
> understand the memory usage issues - sort of - but how does it reduce
> repository size if you need to need to check out all the submodule
> repositories along with the main project anyway?
I've got an eye on submodules as a way of avoiding the need to require a
whole tree clone to just work on parts of it, but that's not really
relevant to my query, just explaining our environment and setting the stage ;)
We're using submodules right now similar to how we used svn externals in
the past (except better, clearly), to incorporate outside components
(like open source projects) that our stack depends on.
> Just looking to clarify for myself. (I'm continuing my work on
> git-subtree, which is getting more and more positive feedback. It
> solves all the *other* problems that you listed vs. submodules, but it
> certainly doesn't resolve any repository size issues.)
Good to know, we're still on Git 1.6.1, are there any benefits or
additional features in more recent releases of Git that help alleviate
the submodules issues I outlined at the top of the thread?
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-05-29 20:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 18:41 Managing submodules on large multi-user projects R. Tyler Ballance
2009-05-29 19:53 ` Avery Pennarun
2009-05-29 20:09 ` R. Tyler Ballance [this message]
2009-05-29 20:18 ` Avery Pennarun
2009-05-29 22:58 ` Felipe Contreras
2009-06-23 22:58 ` R. Tyler Ballance
2009-05-31 13:39 ` Alex Riesen
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=20090529200928.GH11222@starfruit.corp.slide.com \
--to=tyler@slide.com \
--cc=apenwarr@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).