[Tfug] Version Control

Zack Williams zdwzdw at gmail.com
Tue Mar 26 06:58:37 MST 2013


On Mon, Mar 25, 2013 at 11:15 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Though none have given either a "wholehearted" endorsement.

I'll wholeheartedly endorse Git, for managing just about anything.  I
keep my multi-gig document repo in it, etc.

> So, why "obvious"?  :>

"well engineered and not going to go away" :)

Lots of people working  on the code, and large companies relying on it
- heck, Apple and Microsoft both support it in their dev tools.

> What do you consider a large project?  Do they handle independent
> (though related) projects in the same repository?

As Tom mentioned, you can do this with git submodules, but be careful
with these as they can be a bit hairy to work with.

> Silly example:
> - C standard library can be considered a "project"
> - each app that *uses* the library could be considered separate projects
> - the documentation for each of those apps are each separate projects
>   from the apps themselves
>
> I.e., these things are independent but still interelated.  E.g., a
> change in the app can necessitate a change in the documentation...

I'd probably do multiple repos, one for each separate project, but
lump the docs in with the main project.

Unlike CVS and subversion, making different tags and branches and
merging them is downright pleasurable in Git.

>> Handling large binary files requires something like 2-4x object size
>
> "2-4x" the *original* object size?  Why, do they uuencode it before
> processing it?

I haven't looked into exactly why they use a multiple of memory to do
this, but internally they calculate a SHA1 sum on the object before
adding it to the repo, and compare it against other files in order to
save just the changes, and compress it.  This also serves to dedupe
the repo contents.

- Zack




More information about the tfug mailing list