Re: GSoC - Some questions on the idea of

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/11/2012 1:04 AM, Jonathan Nieder wrote:

I would suggest tracking source code instead of binaries if
possible, though.

Reasons why we want to track binaries:
(1) Standard Targets: Our deployment is assembly line style because our
target servers are under our control.
(2) Copy vs. Recompile:  We run certain "supported" linux distro
versions on our target servers so we can just put our binaries on them
instead of recompiling.
(3) In-house-Source Compiled Binaries:  For our particular proprietary
(third-party) source language the binaries run on top of a runtime that
runs on top of the O/S so that makes the need to recompile on a server a
non-issue.  We use xxd and compile listings to "diff" our compiled
binaries to detect missing copybook and data dictionary dependencies (missed recompiles), unnecessary recompiles (you didn't really change what you thought you changed), and miscompiles. We do this compiled binary validation in git branches and then diff the branches to detect the discrepancies.
(4) Proprietary-Third-Party Binaries (no source) Versioning:  For our
third party binaries we don't have the source.  The are distributed as
self-extracting-executables.  Changes to third party binaries are
relatively infrequent but frequent enough to cause confusion and
therefore need to be tracked.
(5) Graphics "Source" Versioning:  Our graphics files are part of our
software and changes need to be tracked.
(6) O/S Versioning:  Our linux distro is tracked in a bazaar repo so
I'm thinking we should be able to track it in a git repo instead.  The
assembly line just deploys the payload to a new server instead of doing
manual install.
(7) Superproject tracking of "Super-release":  The above subsystems are
related in varying degrees (dependent).  A superproject can associate
all the versions that comprise a "super" release of the various
subsystem version dependencies.

While some of the reasons above may be non-normative for some git-users,
I think that a large portion (if not the majority) of git-users will
find some subset of the above reasons normative for their use-cases
(namely reasons 5 and 4) therefore making the necessity for binary
tracking normative for git-users in general.

v/r,
neal

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]