On 11 April 2016 at 23:44, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 3:41 PM, sebb <seb...@gmail.com> wrote:
>
>> On 11 April 2016 at 22:56, Benson Margulies <bimargul...@gmail.com> wrote:
>> > I'm assuming this code hasn't been moved to git, based on the lack of
>> > discussion of same on the relevant web page.
>> >
>>
>> AIUI the dist/ tree will never be moved to Git because it has so much
>> data in it, and it's not possible to check out a part of a Git repo.
>>
>
> Really?

Yes, Git repos can only be checked out wholesale.
And when you clone a repo, you will get everything, including all the history.

With SVN you can check out a part, for example:

https://dist.apache.org/repos/dist/release/commons/io/source

and you will only get the current source archives, not any previous releases.

Git would require you to check out at the project level as a minimum
(it would be too much work to maintain separate repos for each
component) and the clone would include all the archives that were ever
checked in, even those since deleted.

That's the point of the Git distributed system; every clone has everything.

Whereas with SVN only the server has everything - developers can
download just the bit they want.

If you accidentally check in a large file into Git, everyone gets a
copy, even if you then delete it.

AIUI it is possible to remove files completely from Git, but it
requires very careful handling to ensure that the history is not
destroyed.

> It seems like keeping the whole repo is a good idea.

AFAIK Infra *do* keep the whole repo.

>  How much data are we talking about here?

All project artifacts released by all projects since svnpubsub was introduced.

That is quite a lot of data.

> Are we talking about a Git limit or an Apache limit?
>

Neither; it's a limit on what is sensible for developers to attempt to download.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to