On Mon, Mar 23, 2009 at 10:21:41AM -0500, Samman, Bassel wrote:
> Yes, unfortunately they do change occasionally and they grow with
> time. It's a product catalogue, so new products are added all the
> time, just not daily. That's part of why I want to move to Git, SVN
Well, I would first try just importing _one_ repo into git and seeing
how it behaves. I suspect you may run into assumptions that a 50G repo
breaks.
In theory, I think you could pack all of the large files once into a
single pack, mark it with .keep, and then not have it negatively impact
further repacks.
> has been giving me lots of trouble when adding files at deep levels
> and I like how Git does adding files and how each repository is really
> it's own repository. Also, I'm not really concerned about history as
> the main purpose of the repository is really to make the syncing job
> easier. The code is very minimal and I do the majority of the
Well, if you're not too concerned about the history, then I would
suggest setting up something like this:
- all of the big files get a unique name; new versions of the same
file have names unique from their previous version (you can do this
either with human-readable names, or just using the sha-1 of the
file contents)
- make all of the big files available through rsync, http, ftp, or
whatever
- the git (or svn) repo contains a list of all desired files, and a
script that checks what you have versus what is desired (deleting
any that aren't wanted, and pulling any that are missing)
Your repository of big files will grow, but each file within it is
immutable. The git repository points to the files by name, but doesn't
contain them. So updating from a client is just:
git pull && ./update-script
but you can still go back to a snapshot in history if you want to:
git checkout HEAD@{3.weeks.ago} && ./update-script
Make sense?
> can be crazy at times, but what can we do. Also, this is a far fetch,
> since all the projects are installed under the same directories and
> are really exact clones of each other in every way, can I copy the
> .git directory and hope to God that it will magically work. I really
> doubt it, but I figure it's worth asking.
I'm not sure what you mean by that. You can copy the .git directory to a
new working tree, yes. It will be a new repo, and you can see how what
it thinks should be checked out differs from what is in the new working
tree by running "git diff".
-Peff
--
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
