Re: BTRFS and debian
On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> On 07/12/18 10:52, David Wright wrote:
> > On Mon 09 Jul 2018 at 20:33:00 (-0700), David Christensen wrote:
> > > On 07/09/18 11:17, Ge wrote:
> > > > Should i make a different partition for /home/ ?
> > >
> > > I don't -- I put my bulk data on a file server, including all e-mail
> > > attachments. My home directory is ~1 GB.
> > >
> > >
> > > (If/when I want to travel with my laptop, I will need to figure out
> > > how to set up a VPN to my file server.)
> >
> > I would find that rather risky, so I have a "proper" separate,
> > encrypted /home that ranges from 50GiB (laptop) to ~400GiB
> > (desktops)—basically, the rest of the drive, though one laptop
> > gives a fair amount of space over to a W10 installation.
>
> First, I will need to test how the applications I use react to VPN connections going up and down.
>
>
> My file server is also a CVS server. This makes it easy to keep the same files on multiple computers, and to
> synchronize changes. (CVS can solve the three-way merge problem for text files. I need to be mindful when editing
> binary files.)
I've completely replaced CVS with git these days - for all my
hacking of course, as well as parts of home/ - and I finally figured
out how to have a inter-system (or -drive) "git update" work
"properly" by which I mean:
- some repos I am interested in, I grab into home/setups-local with
a quick
git clone git://repo... repo.gits
- Everything ultimately gets backed up onto a file server, on which
when I'm working I grab a repo with
git clone --mirror git://repo... repo.gitm
- The repo.git[ms]/.git/configs need to do the following:
a) in whichever repo I am in/ updating (by script or otherwise), I
want a "git fetch" or "git pull" to Do The Right Thing (TM)(C)(R),
which means:
b) it MUST first get all possible updates from the "other" instance
that I maintain of that repo, including my own personal branches etc
c) only THEN must it download remaining updates from the net
and so to achieve this, the .git/config files look somewhat like
this:
# ~/setups-local/postgresql.gits/.git/config :
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "setups"]
# fetch from "setups"
url = /setups/p/postgresql/postgresql.gitm
fetch = +refs/remotes/origin/*:refs/remotes/setups/*
[remote "origin"]
url = git://github.com/trevorbernard/disruptor-examples.git
fetch = +refs/*:refs/remotes/origin/*
fetch = +refs/heads/*:refs/heads/*
fetch = +refs/tags/*:refs/tags/*
[branch "master"]
remote = origin
merge = refs/heads/master
# /setups/p/postgresql/postgresql.gitm/config :
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "setups-local"]
# fetch from "setups-local"
url = /home/me/setups-local/postgresql.gits
fetch = +refs/remotes/origin/*:refs/remotes/setups-local/*
[remote "origin"]
url = git://git.postgresql.org/git/postgresql.git
fetch = +refs/*:refs/remotes/origin/*
fetch = +refs/heads/*:refs/heads/*
fetch = +refs/tags/*:refs/tags/*
# fetch = +refs/pull/*:refs/remotes/origin/pull/*
# fetch = +refs/pull/*:refs/rpull/origin/*
[remote "pgxc-sf"]
url = git://postgres-xc.git.sourceforge.net/gitroot/postgres-xc/postgres-xc
fetch = +refs/heads/*:refs/remotes/pgxc-sf/*
fetch = +refs/tags/*:refs/rtags/pgxc-sf/*
[remote "pgxc"]
url = git://github.com/postgres-x2/postgres-x2.git
fetch = +refs/heads/*:refs/remotes/pgxc/*
fetch = +refs/tags/*:refs/rtags/pgxc/*
[remote "pgxc-docs"]
url = git://github.com/postgres-x2/implementationDocs.git
fetch = +refs/heads/*:refs/remotes/pgxc-docs/*
fetch = +refs/tags/*:refs/rtags/pgxc-docs/*
[remote "pgxc-webpage"]
url = git://github.com/postgres-x2/webpage.git
fetch = +refs/heads/*:refs/remotes/pgxc-webpage/*
fetch = +refs/tags/*:refs/rtags/pgxc-webpage/*
[remote "pgxc-github.io"]
url = git://github.com/postgres-x2/postgres-x2.github.io.git
fetch = +refs/heads/*:refs/remotes/pgxc-github.io/*
fetch = +refs/tags/*:refs/rtags/pgxc-github.io/*
[remote "pgxl"]
url = git://git.code.sf.net/p/postgres-xl/postgres-xl
fetch = +refs/heads/*:refs/remotes/pgxl/*
fetch = +refs/tags/*:refs/rtags/pgxl/*
[remote "pgxl-tools"]
url = git://git.code.sf.net/p/postgres-xl/tools
fetch = +refs/heads/*:refs/remotes/pgxl-tools/*
fetch = +refs/tags/*:refs/rtags/pgxl-tools/*
In this way, I can update one, then update the other, and I don't
download the updates twice. Yes, each holds an extra set of heads,
tags etc under remotes/setups/ and remotes/setups-local/
respectively, which not only is a very small "price" to pay, but has
actually been useful once or twice when I've messed around with tags
and heads, gotten befuddled and ultimately had to go check the
local "origin" duplicate refs in setups or setups-local, to fix
things up.
This took me a few attempts, a coupla bungles and many googoyle
searches and man page readings, over a year and half, before I
finally got it right. The main problem (besides understanding enough
of remotes and refs) was duplicating the "other" mirror (setups and
setups-local respectively, in the above example) into the current
mirror, without building a deeper and deeper refs hierarchy due to
the inherently recursive tags hierarchy creation with something
simple such as:
[setups]
fetch = +refs/*:refs/remotes/origin/*
[setups-local]
fetch = +refs/*:refs/remotes/origin/*
which would cause an ever-deepening refs hierarchy each time I
swapped from one mirror to the other.
Using fetch = +refs/remotes/origin/*:refs/remotes/setups/* instead,
solves this particular problem - but also means one must add lines
such as the following:
fetch = +refs/heads/*:refs/heads/*
fetch = +refs/tags/*:refs/tags/*
in order for the repo to "work" normally.
Note also my "setups" mirror includes a bunch of other repos which
relate to postgresql - that way, common files are not duplicated
across many local mirrors, instead they're all in a single mirror -
this is particularly useful when one is mirroring various forks of a
large repo, such as Linux kernel. Use commands such as the following
to add an additional remote repo, to a local mirror:
git remote add <name> <url>
And then you can use <name> to checkout branches, or create work dirs
(a nice feature in recent versions of git).
Enjoy,
Reply to: