-
Time we start with the next talk
-
I welcome Richard Hartmann
-
He is involved in Debian since many years
-
and he became recently Debian Developer
-
and he will talk about gitify your life.
-
?, blogs, configs, data and backup. gitify everything
-
Richard Hartmann
-
Thank you. [applause]
-
Thank you for coming
-
expecially those who ? years attended all ?
-
Short thing about myself
-
As ? said I'm Richard Hartmann
-
In my day job I am backbone manager at Globalways
-
I'm involved in freenode and OFTC and...
-
should I speak louder?
-
I'm not...
-
test, test... good back there?
-
Can you turn up the volume a little bit?
-
test, test... ok, perfect.
-
Since about a week I've been a Debian Developer (yay)
-
[applause] and I'm the author of vcsh.
-
Raise of hands: who of you know what git is?
-
perfect
-
That's just as in ? perfect, we can skip it.
-
Let's move to the first tool, etckeeper.
-
Some of maybe most of this audience will have heard of it,
-
it's a tool to basicly store your /etc in pretty much every version control system you can think of
-
It's implemented in POSIX shell
-
it autocommits every thing in /etc basically at every opportunity
-
you may need to write excludes, for example
-
before your network config ?
-
but else, yeah, that's really cool
-
the autocommit
-
it hooks into most of the important or maybe even all of the important package management systems
-
so when you install your packages, even on SuSE or whatever
-
you can just have it commit automatically, which is very nice
-
You can obviously commit manually
-
if you for example change your X config
-
it supports as I said various backends
-
it's quite nice to recover from failures
-
for example ? used it to recover from saturday's power outages
-
because some servers lost stuff and with etckeeper you can just replay all the data which was...
-
rather nice.
-
Then there is bup.
-
bup is a backup tool based on the git pack file format
-
it's written in python
-
it's very very fast
-
and it's very space efficient.
-
The author of bup managed to reduce his own personal backup size
-
from 120 GiB to 45 GiB
-
just by migrating away from rsnapshot over to bup
-
which is quite good
-
I mean, it's almost or a little bit more than a third, so
-
very good
-
This happens because it has built-in deduplication
-
because obviously git pack files also have deduplication
-
You can restore every single mount point
-
or every single point in time
-
every single backup can be monted as FUSE filesystem or a ? filesystem
-
independently of each other
-
so you can even compare different versions of what you have in your backups
-
which again is very nice
-
the one thing which is a real downside for serious deployments
-
there is no way to get data out of your... archive or out of your backups
-
which again is a direct consequence of using git pack files
-
there is a branch which supports deleting old data
-
but this is not in mainline and it hasn't been in mainline for...
-
I think one or two years
-
so I'm not sure if it will ever happen but...
-
yeah
-
at least in theory it would exist.
-
Then for your websites, for your wikis, for your whatever there is ikiwiki.
-
ikiwiki is a wiki compiler,
-
as the name implies,
-
and it converts various different files into HTML files
-
it's written in Perl
-
it supports various backends
-
again most of the ones you can possibly think of
-
oh, I can even slow down, good
-
it's able to parse various markup languages, more on that on the next slide
-
there are several different ways to actually edit any kind of content within ikiwiki
-
it has templating support, it has CSS support
-
these are quite extensive, but they may be improved, but that's for another time
-
it acts as a wiki, as a CMS, as a blog, as a lot of different things
-
it automatically generates RSS and Atom feeds for every single page, for every subdirectory
-
so you can easily subscribe to topical content
-
if you are for example only interested in one part of a particular page
-
just subscribe to this part by RSS
-
and you don't have to check if there updates for it
-
which is very convenient to keep track of comments somewhere or something
-
It supports OpenID, which means you dont have to go through all the trouble of...
-
having a user database or doing very...
-
or doing a lot of antispam measures
-
because it turns out OpenID is relatively well...
-
suited for just...
-
stopping spam. For some reason, maybe they just
-
haven't picked it up yet, I don't know
-
but it's quite nice, because you don't have to do any actual work
-
and people can still edit your content, and you can track back changes at least to some extent
-
it supports various markup languages, the best ones, well, debatable, but in my opinion is Markdown
-
it supports WikiText, reStructuredText, Textile and HTML and there are ikiwiki specific extensions
-
for example normal wikilinks which are a lot more powerful than the normal linking style in MarkDown
-
which kind of sucks, but... whatever
-
it also supports directives, which basically tell ikiwiki to do special things with the page
-
for example you can tag your blog pages
-
or you can make...
-
generate pages which automatically pull in content from different other pages and stuff like this.
-
that's all done by directives.
-
How does it work?
-
You can edit webpages directly, if you want to, on the web
-
then you will have a rebuild of the content
-
but only the parts with changes
-
so if you... hello?
-
if you change only one single file it will only rebuild one single file
-
if you change for example the navigation it will rebuild everything because obviously...
-
it is used by everything.
-
If it has to generate pages automatically, for example the index pages or something
-
if you just create a new subdirectory, or if you have...
-
if you have commands which have to appear on your site
-
it will automatically generate those MarkDown files and commit them
-
or you put them in your souce directory and you just commit them and...
-
and have them part of your site, or you can autocommit them if you want.
-
That's possible as well.
-
You can obviously change... pull in changes in your local repository if you want to look at them
-
Common uses would be public wiki...
-
private notes, for just note keeping of your personal TODO list or whatever
-
having an actual blog, which a lot of people in this room probably do
-
that's, yeah, I mean a lot of people on Planet Debian have their blog on ikiwiki, for good reasons
-
and an actual CMS for company websites or stuff
-
which also tends to work quite well.
-
The three main ways to interact with ikiwiki are webbased text editing, which is quite useful for new users, but is quite boring, in my opinion,
-
there is also a WYSIWYG editor which is even more fancy for non-technical users
-
and there is just plain old CLI-based editing way:
-
just edit files and commit them back into repository pushes up and everything gets rebuilt automatically , which is...
-
in my opinion the best way to interact with ikiwiki, because
-
you are able to stay on the command line and simply push out your...
-
your stuff onto the web and you don'tactually have to leave the command line
-
which is pretty kinda neat.
-
There are also some more advanced use cases
-
as I said you can interface with the source files directly
-
you can maintain...
-
something is wrong
-
for example you can maintain your your wiki and your docs and your...
-
source code in one single directory
-
and it would simply...
-
and simply have parts of your subdirectory structure rendered.
-
for example git-annex does this
-
there is a doc directory, which is rendered to the website
-
but is also part of the normal source directory
-
which means that everybody who checks out a copy of the repository
-
will have the complete forum, bug reports, TODO lists
-
user comments,
-
everything on their local filesystem, without having to leave - again - their command line,
-
which doesn't break media, and so is just very convenient to have one single resource for everything regarding one single program.
-
And another nice thing is if you create different branches
-
for preview, staging areas you can have workflows where some people are just allowed to create ...
-
pages, other people then look over those pages and merge them back into master and then push them on the website
-
which basically allows you to...
-
to have content control or real publishing workflow, if you have a need to do this
-
Next stop: git-annex.
-
The beef.
-
It's basically a tool to manage files with git without checking those files into git
-
?
-
Yeah, what is git-annex?
-
It's based on git,
-
it maintains the metadata about files,
-
as in location, and file names and everything, in your git repository
-
but it doesn't actually maintain the file content within the git repository
-
more on that later
-
this saves a lot of time and space.
-
You still able to use any git-annex repository as a normal git repository
-
which ? means you're even able to have a mix of...
-
for example, say, all your ? files
-
should be maintained by normal git,
-
and then you have all the merging which git does for you and everything
-
and then you have for example your photographs,
-
or your videos for web publishing
-
which are maintained in the annex
-
which means you don't have to have a copy of those files in each and every single location
-
A very nice thing about git-annex is that it's written with very low bandwidth and flaky connections in mind
-
quite a lot of you will know that Joey lives basically in the middle of nowhere
-
which is a great thing to be forced to write really efficient code
-
which doesn't use a lot of data, and that shows:
-
it's really quick
-
and even if you had a really really bad connection
-
in backwaters or whatever...
-
during holidays or during normal living
-
it's still able to transfer the data which you need to transfer,
-
it's very very nice
-
There are various workflows: we'll see four of them in a few minutes
-
So. It's written in Haskell, so it's probably strongly typed and nobody can write patches for it
-
it uses rsync to actually transfer the data,
-
which means it doesn't try to reinvent any wheels
-
it's really just based on top of established and well know and well debugged programs
-
In indirect mode, which in my personal opinion is the better mode,
-
what it does is
-
it moves the actual files into a different location, namely .git/annex/objects
-
it then makes those files read only, so you cannot event accidentally delete those files
-
even if you rm -f them, it will still tell you no, I can't delete them,
-
which is very secure
-
may be incovenient, but you can work on this
-
it replaces those files with symlinks of the same name, and those just point at the object
-
and if there is an object behind this symlink or not...
-
that basically returns whether you are able on this particular machine, or in this particular repository
-
but you will definitely have the informations about the name of the file, the theorethical location of the file...
-
the hash of the file will be in every single repository
-
There is also a direct mode
-
initially mainly written for windows and Mac OS X
-
because Windows just doesn't support symlinks properly
-
and OS X was supporting symlinks,
-
apparently has lots of developers who think it is a great idea to follow symlinks...
-
and display the actual target of the symlink instead of the symlink
-
so you have cryptic filenames which are very hard to deal with
-
obviously people who are used to GUI tools which then only display really really cryptic names ?
-
so there is direct mode which doesn't do the symlink stuff
-
it basically rewrites the files on the fly
-
git still thinks it would be managing symlinks, but...
-
git-annex just pulls them up from under git, and pushes in the actual content.
-
You keep on nodding, so... I'm probably doing good
-
and if you want you can always delete old data, or you can keep it...
-
or you can just... for example what I'm doing:
-
you can have one or two machines which slurp up all your data...
-
and have an everlasting archive of everything which you've ever put into your annexes...
-
and other machines, for example laptops with smaller SSDs
-
those just have the data which you are actually interested in at the moment
-
How does this work in the background?
-
Each repository has a UUID
-
It also has a name, which makes it easier for you to actually interact with the repository...
-
but in the background it's just the UUID for obvious reasons...
-
because it just makes ? and synchronization easy, period
-
It's also tracking informations in a special branch called git-annex
-
this branch means that all...
-
this branch ? every single repository has full and complete informations...
-
about all files, about the locations of all files, about the last status of those files...
-
if those files have been added to some repository
-
or they have been deleted,
-
or if they are being over there forever
-
so in every single repository you can just lookup the status of this file or of all files in all of your repositories
-
which is, yeah, convenient
-
The tracking information is very simple
-
and it's designed to be merged very...
-
it's a little bit more complicated than applying union merge,
-
but basically what it does is it adds a timestamp
-
and tells if the file is there or not and it has the UUID of the repository
-
and from this informations, along with the timestamps you can simply reproduce...
-
the whole lifecycle of your files through your whole cloud of git-annex repositories
-
in this one particular annex.
-
One really nice which you can do is...
-
if you are on the command line, which again in my opinion is the better mode...
-
you can simply run git-annex sync
-
which basically does a commit...
-
oh, it does a git-annex add, then it does a commit,
-
then it merges from the other repositories
-
into your own master, into your own git-annex branch
-
then it merges the log files
-
that's where the git-annex branch comes in
-
and then it pushes to all other known repositories
-
which is basically a one-shot command to syncronize all the metadata about all the files with all the other repositories
-
and it takes no time at all
-
given a network connection
-
Data integrity is something which is very important for...
-
yeah, for all of the tools, but git-annex was really designed with data integrity in mind
-
by default it uses a SHA-2 256 with file extension...
-
to store the objects, so it renames the file to its own shasum
-
which allows you to always verify the data even without git-annex
-
you are able to say by means of globbing...
-
which files, or which directory, or which types of files should have how many copies in different repositories
-
so for example what I do:
-
all my raw files, all theraw photographs are in at least three different locations,
-
all the JPEGs are only in two, because JPEGs can be regenerated
-
raws can not.
-
All remotes and all special remotes can always be verified
-
with special remotes this may take quite some bandwidth
-
with actual normal git-annex remotes you run the verification locally
-
and just report back the results with obviously saves a lot of bandwidth and transfer time
-
verification obviously takes the amount of requires copies into account
-
so if you would have to have 3 different copies
-
and your whole repository cloud only has 2, it will complain
-
it will tell you "yes, checksum is great, but you don't have enough copies, please do something about it".
-
and even if you ? right now, delete all copies from git annex
-
you would still be able to get all your data out of git annex
-
because what it boils down to, in indirect mode, it's just symlinks to other objects
-
these objects have their own checksum as their file name
-
so you'll even be able to verify, without git-annex,
-
just by means of a little bit of shell scripting,
-
that all your files are correct,
-
that you don't have any bit flips or anything on your local disk.
-
direct mode doesn't really need a recovery ?, because...
-
the actual file is just in place of the symlink
-
but on the other hand you won't be...
-
you still need to look at the git-annex branch to determine the actual checksums
-
which you wouldn't have to do with the indirect mode.
-
There are a lot of special remotes. And what are special remotes?
-
these are able to store data in non git-annex remotes
-
because, let's face it, on most servers, or most servers where you could store data
-
you aren't actually able to get a shell and execute commands
-
you can just push data to it, you can receive data
-
but you cannot actually execute anything on this computer.
-
That's what special remotes are for.
-
All special remotes support encrypted data storage
-
so you just gpg encrypt your data and then send it off
-
which means that the remotes can only see the file names
-
but they cannot see anything else about the contents of your files
-
obviously you don't want to trust amazon or anyone to store your plain text data
-
that would just be stupid
-
There is a hook system, which allows you to write a lot of new special remotes
-
you'll see a list of... quite an extensive list of stuff in a second
-
Normal, built-in, special remotes which are supported by haskell out of the box
-
by git-annex out of the box
-
and actually implemented in haskell
-
are Amazon Glacier, Amazion S3, bup, directory — a normal directory on your system
-
rsync, webdav, http or ftp and the hook system
-
there is a guy who brought most of those
-
we can support archive.org, IMAP, box.com, Google Drive... you can read them yourself, I mean...
-
but those are quite a lot of different special remotes, if you...
-
already have storage on any of those services, just start pushing encrypted data to it if you want, and you're basically done.
-
There is an ongoing project called the git-annex assistant
-
last year, and I think this year it just ended, didn't it?
-
so, pretty much exactly one year ago Joey has started to to raise funds
-
by means of a kickstarter to just focus on writing git-annex assistant for a few months
-
he got so much that he could do it for a whole year
-
and he's just restarted the whole thing with his own fundraising campaign without kickstarter and he got another full year
-
yeah... are you still accepting funds?
-
ok, so, if you use it at least consider donating
-
because honesty you can't write patches for it anyway, because it's in haskell, so...
-
that's... the other means of actually contributing
-
git-annex boils down to be a daemon, which runs in the background
-
and keeps track of all of your files, of newly added files
-
and then starts transferring those files, if configured to do so
-
it starts transferring files to other people or to other repositories
-
this is all managed by means of a web gui
-
which in turns means that it's really, well, not easy, but easier to port to for example windows or android
-
which both work, to some extent
-
not fully, but they are useful, or useable, more or less
-
at least on android it's really quite good, I couldn't test it on windows, because...
-
and it also makes it accessible for non technical users
-
so for example if you want to share some of your photographs with your parents
-
or with friends, or if you want to share, I don't know, videos with other people
-
you just put them into one of those repositories
-
and even those non-technical people just magically see stuff appear in their own repository
-
and can just pull the data if they want to
-
or if you configured it to do so, it would it would even transfer all the data automatically
-
which is... it's ?
-
It supports content notifications, but not content transfer
-
by means of xmpp or jabber
-
which used to work quite well with google talk, I think it's not...
-
oh, it still works, ok
-
at least at the moment, we'll see when they just ? google ? with google+, but...
-
at least at the moment it still works, if you have a google account you can simply transfer all your data
-
you can transfer the metadata about your data, you cannot actually transfer the files through jabber
-
but that's probably something which will happen within the next year
-
there are quite ? rulesets for content distribution
-
so for example I can show you...
-
you can say "put all raw files into this archive, and all jpegs on my laptop", or whatever
-
or "if I still have more than 500 GB free on this please put data in
-
and as soon as only have 20 left stop putting data into this one repository"
-
which obviously is quite convenient
-
as I said there is a windows port, and now on to usecases.
-
First usecase: the archivist.
-
What the archivist does is: basically he just collects data
-
either to ? or just to collect
-
and if you have this usecase what you probably want to do, you want to have offline disks
-
to store at your mom's, or to put into a drawer
-
or just you don't have enough sata ports in your computer because you just have so much data
-
so, what you can do is you can just push this data to either connected machines or to disconnected drives...
-
or to some webservice, and just store data
-
but normally you would have the problem of keeping track of where your data lives
-
if it's still ok, if it's still there, everything.
-
With git-annex you can automate all this administrative side of archiving your stuff.
-
Even if you only have one of those disks, if they're a proper remote...
-
you'll have full informations about all the data in your annex cloud up to this point
-
so even if you only pull out one random disk you still have informations on all the other disks on this one disk
-
which obviously is a nice thing.
-
Media consumption.
-
Let's say you pull a video of this talk, or you get some slides...
-
maybe also from this talk, you can get some podcasts...
-
and git-annex has become a native podcatcher quite recently, I thing two or three weeks ago
-
which means you don't even have a separate podcatcher
-
you just tell git-annex "this is all of my rss feeds" and it will just pull in all the content,
-
Then you can synchronize all this data for example to your cellphone, or your tablet, or whatever
-
consume the data on any of your devices, even if you have 10 copies of this particular podcast
-
because you didn't get around to listen to it on your computer...
-
and you didn't get around to listen to it on your cellphone
-
but then on your tablet you did listen to it
-
you have three copies of this file which you don't need anymore...
-
because you have listened to the content and you don't care about the content anymore
-
what you do is you drop this content on one random repository
-
and this information that you have dropped the actual content,
-
not the metadata about the content, but the actual content, you don't need the content anymore...
-
will slowly propagate to all of the annexes and if they have the data they will also drop the data
-
so you don't have to really care about keeping track of those things
-
you can simply have this message propagate
-
do you want to comment? can someone give Joey a microphone?
-
Just a minor correction
-
it doesn't propagate that you've dropped the content
-
but you can move it around in ways that have exactly the effect you described
-
? get the wrong idea that if you accidentally remove one thing it will vanish from everything ?
-
but if you deliberately drop the content and tell the annex...
-
no. that's not how it works.
-
I want to talk about it later, but it's...
-
you looked at the slides, but...
-
sorry, ?
-
He watches for everything which is ?
-
Next thing, if you are on the road, and one usecase which is probably quite common: taking pictures while you are on the road ?
-
You take your pictures, you save them to your annex
-
where you are able to store them back to your server or wherever
-
if you want to, and even if for example one disk gets ?
-
and you lose part of your content,
-
you'll still at least be able to have an overview of what content used to be in your annex
-
and if you then pull out your old SD card and see "oh, that photo is still there" you can simply reimport it and it will magically reappear.
-
What it also does is:
-
if you have a very tiny computer with you
-
you can, as soon as you are at an internet cafe, just sync up with your server or your storage, whatever
-
and push out the data to your remotes
-
which then means you'll have two or three or five copies of the data
-
and git-annex keeps track of what is where for you
-
so you don't have to worry about copying stuff around.
-
And then there is one personal usecase, for photographs
-
I have a very specific way of organizing my photographs
-
my wife disagrees violently
-
she likes to do her photo storage in a completely different way
-
she doesn't care about the raw files
-
and she doesn't care about all the documentation pictures of signposts or whatever which I just took to remember which cities we went through
-
so what she can do is she can simply delete the actual files or ? the symlink of this file
-
and it will disappear from her own annex
-
she can then commit all this
-
normally if she would sync back the data I would also have the same layout, which I don't want
-
expecially since she tends to rename everything a lot
-
but what I did, I set up a rebasing branch on top of my normal git-annex repository
-
so what she gets is: she has her own view of the whole data
-
or the part she cares about
-
and when I add new content
-
she will see the new content, she will rearrange the content however she pleases
-
but as it's a rebasing branch
-
all her changes will always be replayed on top of master
-
so she has her own view, and I don't even notice her own view
-
but even if she uses one of the other computers she would have the same view which she herself has
-
so basically she has her own view all of the data
-
This is very convenient to keep the peace at home.
-
Next topic: vcsh.
-
Most of you here probably have some sort of system...
-
where they have one subversion or cvs or whatever repository
-
and they have it somewhere in their home directory
-
you symlink into various places in your home directory, and it kind of keeps working so you don't throw it away, but...
-
to be honest it sucks. Here is why.
-
Or, here's why in a second.
-
vcsh is implemented in POSIX, which is very very portable
-
it's based on git, but it's not directly git
-
The one thing which git is not able to do is maintain several different working copies into one dicrrectory
-
which is a safety feature, more on that later
-
but this really sucks if you want to maintain your mplayer, your shell, your whatever configuration
-
in your home directory, which is the obvious and only real place where it makes sense to put your configuration
-
you don't want to put it into dot-dot-files and then symlink back
-
you want to have it in your home directory as actual files.
-
So, vcsh uses fake bare git repositories
-
again, more on that on the next slide
-
and it's basically a wrapper around git
-
which makes git do stuff which it normally wouldn't do
-
and it has a quite extensible and useful hook system which ? will care about
-
Whith a normal git repository you have two really defining variables within git
-
you have the work tree
-
which is where your actual files live
-
and you have the $GIT_DIR, where the actual data lives
-
normaly in a normal checkout you just have your directory and .git under this
-
If you have a bare repository you obviously don't have an actual checkout of your data
-
you have just all the objects and the configuration stuff
-
so that's what a bare repository boils down to being
-
A fake bare git repository on the other hand has both
-
it has a $GIT_WORK_TREE and it has a $GIT_DIR
-
but those are detached from each other
-
they don't have to be closely tied together
-
and also sets core.bare = false, to actually tell git that "yes, this is a real setup, but..."
-
"yes, you still have a work tree, even thought you don't really expect it"
-
"to have one, you still have a work tree".
-
By default vcsh puts your work tree into home
-
and your git dir into...
-
it's based on .config/vcsh/repo.d and then the name of the repository
-
which just puts it away and out the way of you actually seeing stuff
-
but it follows the cross desktop specifications so if you move stuff around it will also follow
-
Fake bare repositories are really...
-
are messy to setup, and it's very easy to get them wrong
-
that is also the reason why git normally disallows this kind of stuff
-
because all of a sudden you have a lot of...
-
context-dependency on when you do what
-
just immagine you set git workdir...
-
$GIT_WORK_DIR, sorry
-
and run random commands like git add, that's...
-
kind of ok, if you git reset --hard you'll probably not be to happy
-
you checkout the current version that's also quite bad
-
and if you clean -f, yeah, you just throw the home directory
-
congratulations
-
So, it's really risky to run with these variables set
-
which is why I wrote vcsh to wrap around git
-
to hide all this complexity and do quite some sanity checks to make sure everything's set up correctly
-
again it allows you to have several repositories and it also manages really the complete lifecycle of all your repositories
-
it's very easy to just create a new repository, you just init, just with git
-
you add stuff, you commit it, and you define a remote and start pushing to this remote
-
simple
-
This looks like git because it's very closely tight to git
-
and it uses a lot of the power or of the syntax of git, for obvious reasons
-
because... it's closely tight to git
-
you can simply clone as you would with git
-
you can simply show your files as you would with git
-
you can rename the repository, which git can't do, but you don't have to
-
you can show the status of all your files
-
or just of one of your repositories
-
or of all repositories
-
you can pull in all your repositories at once, you can push all of your repositories at once
-
with one single command
-
so, if you are on the road, or you just want to sync up a new machine it's really quick, it's really easy
-
There are three modes of dealing with your repositories
-
default mode is the quickest to type
-
you just say vcsh zsh commit whatever or any random git command
-
but you cannot really run gitk
-
you can do this by using the run mode, which is the second mode
-
we simply ? here run is missing and here git is missing
-
so you say simply vcsh run zsh git commit whatever
-
and this is exactly the same command, it's literally the same comand once it arrives at the shell level, so to speak
-
here you can also run gitk, because...
-
with this, you set up the whole environment for one single command to run with this context
-
of the changed environment variables
-
or you could even enter the repository, then you set all the variables
-
and then you can just use normal git commands as you would normally
-
this is the most powerful mode,
-
but it's also the most likely to hurt you if you don't know what you're doing
-
so I don't recommend working ? down this way.
-
You should have your shell display prompt information about being in a vcsh repository or not
-
simply because else you may forget that you entered something
-
and then if you run those commands, there will be pain
-
At once the usecases, which will be possible quite soon
-
we can just combine vcsh with git-annex to manage everything which is not configuration files in your own home directory
-
? basically two programs to sync everything about all of your home directory
-
without having to do any extra work
-
you can also use it to do really wierd stuff
-
for example you can backup a .git of a different repository with the help of vcsh
-
so you can just go in, change objects or anything, break stuff and just replay whatever you're doing
-
just to try and see how it breaks in interesting ways.
-
You can just backup a working copy which is maintained by a different reopository or a different system
-
you can even put a whole repository, including the .git,
-
into a different git file
-
or you can even put other VCSs like subversion or something into git, if you want to.
-
Then there is mr.
-
mr ties all those...
-
hopefully by now you have about twenty new repositories
-
because you have configuration, you have ikiwiki, you have everything
-
so now you need something to syncronize all those repositories
-
because doing it by hand is just a lot of work
-
mr supports push, pull, commit operations for all the major known version control systems
-
allowing you to have one single interface to operate on all your systems
-
It's quite trivial to write support for new systems
-
I think it took me about two hours to support vcsh natively
-
so, that's really quick
-
If you want to try, the stuff which I told you about...
-
in the links later there will be the possibility to just clone a subrepository for vcsh
-
which will then put up a suggested mr directory layout
-
and you can just work from there
-
This is the... alright, it's my suggested layout
-
which basically...
-
you just include everything in config.d you maintain...
-
your available.d, by means of vcsh, so you simply sync around all your content between all the different computers
-
and then you simply soft link from available to the actual config
-
which is basically what apache does with sites.enabled and sites.available
-
or modules.available and modules.enabled
-
which is really really powerful
-
Last thing is not git based, but zsh.
-
It's a really powerful shell, you should consider using it
-
it has very good tab complection for all the tools listed here, more than bash
-
it has a right prompt, which will automatically disappear if it needs to
-
which is very convenient to display not important but still useful information
-
and it will automatically, if you tell it to, tell you about you being in a git repository or subversion repository or whatever
-
by means of vcs.info
-
which also means you'll be told that at the moment you are in a vcsh repository
-
and you may kill your stuff if you do things wrong
-
it can mimic all the major shells
-
and there's just too many reasons to list
-
So... final pitch
-
This is true: I've tried it earlier, I can demo it, I still have five minutes left
-
it takes me less than five minutes to syncronize my complete, whole, digital life while on the road
-
so if I'm at the airport and just want to update all my stuff,and push out all my stuff...
-
it'll take a few minutes, but then I can hop on the airplane...
-
and I'll know everything is fine, everything is up-to-date on my local machine
-
on my laptop machine, I can continue working, and have a backup on my remote systems
-
These are the websites
-
The slides will be linked from penta, so you are more than welcome to look at these links later
-
There are previous talks, which you can also look at, if you want to
-
and that's pretty much it
-
and if you have any more questions afterwards either catch me...
-
or there is an IRC channel, and there is a mailing list
-
ok, we can take a few questions, we have still a few minutes
-
then if there are more questions ask Ritchie afterwards
-
And while we are doing this just look here, because that's a complete sync of everything I have
-
Just to make sure I understood this correctly,
-
with git-annex the point is that the data is stored dispersed over different local destinations, so to speak
-
but the metadata ? exists, ? complete git history
-
so git is able to tell me, "well, this version at that destination was changed at that time and so on and so on"
-
did I get this right or...
-
git will be able to tell you about changes...
-
ok, I don't have internet, sorry
-
git will be able to tell you about changes in the filenames, or directory structure
-
git-annex will be able to tell you about changes in the actual file content
-
or in moving around the files
-
but as one single unit, more or less, then yes...
-
the answer is yes, but not quite, but yes
-
yes, but ? all the things you asked about are in git, you know the previous location, all that stuff
-
but in a separate branch which you should use git-annex to access, but you can do it by hand if you want to
-
I'm not familiar with tracking branches,
-
yet you mention that the workflow for your wife has a different view of the data than you
-
with that workflow is it possible for your wife to upload photos that you will have in your view as well, or is it a oneway street?
-
minor correction: tracking branches track a different repository,
-
what I meant was rebasing branches, which rebase on top of a different branch
-
which basically just keeps the patches always on top of the branch, no matter where the head moves to
-
if she wanted to do that she would need to simply git checkout master
-
do whatever she wanted to do, and then git checkout her own branch, and then she's...
-
she is able to, but she would need to change into the master branch and then back
-
microphone
-
she never pushes her private branch? it always lives on her own machine?
-
no, she does push it, but I don't display this view of the data
-
because else she wouldn't be able to syncronize this view between different computers
-
I seem to have internet now, so let's just let this run in the background
-
any more questions?
-
no more questions?
-
than we...
-
? more minutes for questions?
-
ok, so thanks to Richard Hartmann, we will continue...