From: Konstantin Khomoutov <flatworm@users.sourceforge.net>
To: "Stewart, Louis (IS)" <louis.stewart@ngc.com>
Cc: Junio C Hamano <gitster@pobox.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: EXT :Re: GIT and large files
Date: Tue, 20 May 2014 23:01:34 +0400 [thread overview]
Message-ID: <20140520230134.25cbbffe1b0ce95de60024a5@domain007.com> (raw)
In-Reply-To: <C755E6FBF6DC4447BEF161CE48BDE0BD2F0CD670@XMBVAG73.northgrum.com>
On Tue, 20 May 2014 18:18:08 +0000
"Stewart, Louis (IS)" <louis.stewart@ngc.com> wrote:
> From you response then there is a method to only obtain the Project,
> Directory and Files (which could hold 80 GBs of data) and not the
> rest of the Repository that contained the full overall Projects?
Please google the phrase "Git shallow cloning".
I would also recommend to read up on git-annex [1].
You might also consider using Subversion as it seems you do not need
most benefits Git has over it and want certain benefits Subversion has
over Git:
* You don't need a distributed VCS (as you don't want each developer to
have a full clone).
* You only need a single slice of the repository history at any given
revision on a developer's machine, and this is *almost* what
Subversion does: it will keep the so-called "base" (or "pristine")
versions of files comprising the revision you will check out, plus
the checked out files theirselves. So, twice the space of the files
comprising a revision.
* Subversion allows you to check out only a single folder out of the
entire revision.
* IIRC, subversion supports locks, when a developer might tell the
server they're editing a file, and this will prevent other devs from
locking the same file. This might be used to serialize editions of
huge and/or unmergeable files. Git can't do that (without
non-standard tools deployed on the side or a centralized "meeting
point" repository).
My point is that while Git is fantastic for managing source code
projects and project of similar types with regard to their contents,
it seems your requirements are mainly not suitable for the use case
Git is best tailored for. Your apparent lack of familiarity with Git
might as well bite you later should you pick it right now. At least
please consider reading a book or some other introduction-level
material on Git to get the feeling of typical workflows used with it.
1. https://git-annex.branchable.com/
next prev parent reply other threads:[~2014-05-20 19:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 15:37 GIT and large files Stewart, Louis (IS)
2014-05-20 16:03 ` Jason Pyeron
[not found] ` <CALygMcCifDd4LAddZJ4tNcqqwBSvb6BGzTODHBzshBOjCwSrHQ@mail.gmail.com>
2014-05-20 16:53 ` EXT :Re: " Stewart, Louis (IS)
2014-05-20 17:08 ` Marius Storm-Olsen
2014-05-20 17:18 ` Junio C Hamano
2014-05-20 17:24 ` EXT :Re: " Stewart, Louis (IS)
2014-05-20 18:14 ` Junio C Hamano
2014-05-20 18:18 ` Stewart, Louis (IS)
2014-05-20 19:01 ` Konstantin Khomoutov [this message]
2014-05-20 18:27 ` Thomas Braun
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=20140520230134.25cbbffe1b0ce95de60024a5@domain007.com \
--to=flatworm@users.sourceforge.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=louis.stewart@ngc.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;
as well as URLs for NNTP newsgroup(s).