Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Best practice to store .jar files in VCS (SVN, Git, …): don't.</p> <p>It could make sense in a CVCS (Centralized VCS) like SVN, which can handle millions of files whatever their size is.</p> <p>It doesn't in a DVCS, especially one like Git (and <a href="https://stackoverflow.com/questions/984707/what-are-the-git-limits/984973#984973">its limits</a>): </p> <ul> <li>Binary files <a href="https://stackoverflow.com/questions/2266737/git-style-backup-of-binary-files/2266961#2266961">don't fit well with VCS</a>.</li> <li>By default, cloning a DVCS repo will get you <em>all</em> of its history, with all the jar versions.<br> That will be slow and take a lot of disk space, not matter how well those jar are compressed.<br> You could try to play with <a href="https://stackoverflow.com/questions/2586824/partial-clone-with-git-and-mercurial/2587244#2587244">shallow cloning</a>, but that's highly unpractical.</li> </ul> <p>Use a second repository, like <strong><a href="http://nexus.sonatype.org/" rel="nofollow noreferrer">Nexus</a></strong>, for storing those jars, and only reference a <code>txt</code> file (or a <code>pom.xml</code> file for <strong><a href="http://maven.apache.org/" rel="nofollow noreferrer">Maven</a></strong> project) in order to fetch the right jar versions.<br> A artifact repo is more adapted for <a href="https://stackoverflow.com/questions/2888299/is-there-any-disadvantage-to-putting-api-code-into-a-jar-along-with-the-classes/2888312#2888312">distribution and release management purpose</a>.</p> <hr> <p>All that being said, if you <em>must</em> store jar in a Git repo, I would have recommend initially to store them in their compressed format (which is the default format for a jar: see <a href="http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/deployment/jar/build.html" rel="nofollow noreferrer">Creating a JAR File</a>)<br> Both compressed and uncompressed format would be treated as binary by Git, but at least, in a compressed format, clone and checkout would take less time.</p> <p>However, many threads mentions the possibility to <a href="http://lists.zerezo.com/git/msg643319.html" rel="nofollow noreferrer">store jar in uncompressed format</a>:</p> <blockquote> <p>I'm using some repos that get regular 50MB tarballs checked into them.<br> I convinced them to not compress the tarballs, and git does a fairly decent job of doing delta compression between them (although it needs quite a bit of RAM to do so).</p> </blockquote> <p>You have more on <a href="http://osdir.com/ml/git/2009-04/msg01221.html" rel="nofollow noreferrer">deltified object on Git here</a>:</p> <blockquote> <ul> <li>It does not make a difference if you are dealing with binary or text;</li> <li>The delta is not necessarily against the same path in the previous revision, so even a new file added to the history can be stored in a delitified form;</li> <li>When an object stored in the deltified representation is used, it would incur more cost than using the same object in the compressed base representation. The deltification mechanism makes a trade-off taking this cost into account, as well as the space efficiency.</li> </ul> </blockquote> <p>So, if clones and checkouts are not common operations that you would have to perform every 5 minutes, storing jar in an uncompressed format in Git would make more sense because:</p> <ul> <li>Git would compressed/compute delta for those files</li> <li>You would end up with uncompressed jar in your working directory, jars which could then potentially be loaded more quickly.</li> </ul> <p><strong>Recommendation: uncompressed</strong>.</p>
    singulars
    1. This table or related slice is empty.
    1. POBest practice to store .jar files in VCS (SVN, Git, ...)
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USVonC
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POBest practice to store .jar files in VCS (SVN, Git, ...)
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you for answering although this does not answer my question. Sometimes it makes sense (for us) to store jar files in a repository. For that case I want to know what's best - compressed or uncompressed.
      singulars
      1. PO
      1. USMot
    2. CO@mklhmnn: all right, I have added my recommendation, at least for Git: uncompressed format for jar is worth a try.
      singulars
      1. PO
      1. USVonC
    3. CO"uncompressed format ... is worth a try" vs. "I ... recommend to store ... in ... compressed format" seems contradictionary for me. Do you suggest compressed or uncompressed?
      singulars
      1. PO
      1. USMot
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload