No need to keep tars in repository

[drdhaval2785]

Now we have shifted to the release method for tar distribution. There we do drag and drop from local machine for tar.gz. github stores them as separate items.

The tars in tar directory have nothing to do with these releases. We can save a lot of space and reduce commit size if we stop uploading tars.gz, .dict.dz, .idx, .ifo and .syn files into the repository. We will only commit changes in .babylon and .babylon_final into the repository. Then git will be able to show differences effectively as they are text only.

Requests -

1. Keep only .babylon and .babylon_final in the git repository and remove other files
2. Remove tar folders. Keep only tars.MD.
3. Submit all tar.gz to the release page only.

[vvasuki]

Retaining the .dict.dz, .idx, .ifo and .syn files in the repository is helpful for laptop users like me who can just clone the repo (at depth 1) and import everything recursively as below in goldendict:

I agree that there is no need to retain tars once they're moved to release and the contributor is satisfied that all is well. They can just be deleted by the contributor without checking them in (+ git rm for older files). I'll just add a note to that effect in the README

[drdhaval2785]

What do the tars do? They hold the files in compressed format. We have tars in releases which contain .dict.dz, .ifo, .syn, .idx files. So we can create some small script which can download latest tars from release pages. untarring locally is better than keeping dual version (one tarred and one untarred).

We have all necessary ingredients to download from release directly rather than git clone depth 1.

1. We have a list of files uploaded in the release in tars.MD
2. we have gzip in our computers.

So my concern is still to remove these four files from the repository too.

[drdhaval2785]

git is designed to be a version control system and not a dumping site for binaries. So let us keep github repository clean and use release pages for binaries. Actually we need to focus and track changes in the babylon files only. Rest all is automated thanks to your great effort.

[vvasuki]

git is designed to be a version control system and not a dumping site for binaries.

Just because a tool is designed for one thing one need not infer that it is not good for another :-)

So let us keep github repository clean and use release pages for binaries.

Disagree here - plz see below.

Actually we need to focus and track changes in the babylon files only.

No dispute there. That's the main thing.

So we can create some small script which can download latest tars from release pages.

A script for every operating system? Why not just let people download and extract a zip? As in here: Why reinvent the wheel?

untarring locally is better than keeping dual version (one tarred and one untarred).

Two versions are not a big problem in our case.. We can assume that both are ready to be used (even if different, user can pick what he wants if he's particular).

[drdhaval2785]

Multi GB github repository is not a good idea if we want it to be user friendly. Rethink. I strongly feel it is not at all necessary to keep these files in github. You decide.

[vvasuki]

The developers I am not worried about. They can do git clone depth 1. Repo size (big already due to past history) doesn't matter for them.

Desktop users on the other hand - they wouldn't even know how to run git clone, and getting the zip file on the file as shown above leads to inclusion of unnecessary tar.gz files. For them it is desirable to zip all the necessary files, put it in release and publish a link. That's independent of this problem - will open a fresh issue.

[gasyoun]

they wouldn't even know how to run git clone

Only a few know.

[drdhaval2785]

I withdraw my proposal because our majority users are not techies.

[vvasuki]

विषये ऽस्मिन् विकल्पान्तराण्य् अचिन्तयम्। तद्यथा -

• push tars to github-pages branch where it would be served in a website. (requires too much effort)
• push tars are pushed to a separate branches (no website), whence it would be downloaded.
• push tars into a particular reused release using commandline tools (overwriting possible? deleting obsolete tars?).

एतेष्वन्यतमस्य साधनाय मार्गौ, ययोर् द्वितीयं सरलतरम्-

• wercker/ travis build
• makefile invocation.

अन्ततो गत्वा ऽस्य कृते महान् हि श्रमो ऽपेक्ष्यत इति त्यक्तम्।

किञ्च यथा सूचितम् .ifo .dict.dz इत्यादयो मध्यमफलानि नेतः परं स्युर् अत्र गिट्केन्द्रय् प्रकाशितानि।