Re: About single user setup for lightweights

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

 



On Thu, Mar 18, 2010 at 9:53 PM, Harry Putnam <reader@xxxxxxxxxxx> 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
--
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]