git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avery Pennarun <apenwarr@gmail.com>
To: Harry Putnam <reader@newsguy.com>
Cc: git@vger.kernel.org, bazaar@lists.canonical.com, mercurial@selenic.com
Subject: Re: About single user setup for lightweights
Date: Thu, 18 Mar 2010 22:13:53 -0400	[thread overview]
Message-ID: <32541b131003181913v7319d6a1ydd72c0177729dbf4@mail.gmail.com> (raw)
In-Reply-To: <87r5nht6uf.fsf@newsguy.com>

On Thu, Mar 18, 2010 at 9:53 PM, Harry Putnam <reader@newsguy.com> wrote:
> I keep a central cvs repo and on each host I do a check out of the
> entire thing from the base up.  Mostly to have copies of various style
> of rc files the  OSs need but also to keep the scripts I've written
> over the years and learned to rely on, available and in sync.
>
> To me, keeping up with cvs is always a PITA.  I've never hit on a
> handy and efficient way to do it. Even for a just my light usage.
[...]
> How would a workflow actually go:
> I'd create and populate a repo, then what?.  Create clones on each
> machine I guess and if I found a need to change or add files, I'd then
> push back to the original repo?  Its sounding a whole lot like cvs so far.

Yes.  Or you could skip the central repo and pull directly from one
machine's working tree to another.  If that has any value to you, then
it's the only likely reason a DVCS would do you any good for this
trivial case.

The real question is: what makes your current setup a PITA?  If you
can't answer that concisely, then you don't know what to look for in a
supposedly better solution.

> Anther thing I'm really curious about concerns binary rcs.  I'm thinking
> of photo editing and things like flash where I might be changing a
> project over time and want access to past versions.
>
> I'm told cvs is not good for that... consequently I've never tried
> it.  Am I likely to find that one of git, mercurial or bazaar is far
> better for that?

git sucks at handling large binary files (>50 megs or so) unless you
have boatloads of RAM.  If your binary files are moderately sized (a
few megs) then it'll probably be reasonably efficient.  I don't know
about hg and bzr for memory usage.

It's better to store uncompressed binary files (eg *.tar) instead of
compressed ones (*.tar.gz) in order to allow useful delta compression.
 That means raw images instead of png/gif/jpg.  And probably completed
flash files are compressed.  The best thing to do is actually try it
and see if your repository size and memory usage is reasonable.

Have fun,

Avery

  reply	other threads:[~2010-03-19  2:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19  1:53 About single user setup for lightweights Harry Putnam
2010-03-19  2:13 ` Avery Pennarun [this message]
2010-03-19  9:53   ` Martin Geisler
2010-03-19 17:14     ` Avery Pennarun
2010-03-19  4:01 ` Ben Finney
2010-03-19 14:08 ` Sitaram Chamarty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32541b131003181913v7319d6a1ydd72c0177729dbf4@mail.gmail.com \
    --to=apenwarr@gmail.com \
    --cc=bazaar@lists.canonical.com \
    --cc=git@vger.kernel.org \
    --cc=mercurial@selenic.com \
    --cc=reader@newsguy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).