artifactory and delta compression (delta difference / delta storage)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

artifactory and delta compression (delta difference / delta storage)

daytalker
Hi folks,

one short question:
how does artifactory store binaries? I know about the checksum approach by JFrog, but this only helps to prevent artifactory storing the same file twice.

How are the differences between binaries stored if only one file is changed within a binary?
As I know e.g. GIT is able to store binaries with delta storage methods, means that not the complete binary has to be stored all the time but only the difference between two versions.

Is artifactory able to handle binaries this way?

Greetings,
daytalker
Reply | Threaded
Open this post in threaded view
|

Re: artifactory and delta compression (delta difference / delta storage)

dave_p
I only did limited testing of the du -sh * variety, when we deployed it,
but I don't _think_ Artifactory does "delta storage."

That said, most NAS/SAN platforms offer dedup. So it should be fairly
simple to do it at the storage level. (Our artifactory filestore is on a
dedup-enabled NAS. Works fine.)

-Dave

On 4/30/2014 10:27 AM, daytalker wrote:

> Hi folks,
>
> one short question:
> how does artifactory store binaries? I know about the checksum approach by
> JFrog, but this only helps to prevent artifactory storing the same file
> twice.
>
> How are the differences between binaries stored if only one file is changed
> within a binary?
> As I know e.g. GIT is able to store binaries with delta storage methods,
> means that not the complete binary has to be stored all the time but only
> the difference between two versions.
>
> Is artifactory able to handle binaries this way?
>
> Greetings,
> daytalker
>
>
>
> --
> View this message in context: http://forums.jfrog.org/artifactory-and-delta-compression-delta-difference-delta-storage-tp7579789.html
> Sent from the Artifactory - Users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Artifactory-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>

--
Dave Pierce
Engineering Services (MDC)
Dell | Compellent
[hidden email]

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
Reply | Threaded
Open this post in threaded view
|

Re: artifactory and delta compression (delta difference / delta storage)

itamarb
Hi,

Any change to the files within a binary would create a new binary with different checksums, so this artifact will be deployed as a different artifact and will be stored separately in the storage.

Currently, Artifactory does not support storing binaries with delta storage methods.

Regards,
Itamar.
Reply | Threaded
Open this post in threaded view
|

Re: artifactory and delta compression (delta difference / delta storage)

daytalker
Thanks for this answer itamarb,

you speak of "currently" - does this means it is planned by JFrog?
I think this is a really necessary feature as artifactory does not really support multi-OS layers. Means you need sooner or later storage which cannot be handled anymore.

Greetings,
Simon