[-- Attachment #1.1: Type: text/plain, Size: 2765 bytes --] Regarding the synchronizing of directories on two or more machines, using a USB Stick. Further questions after a bit of experimentation. I am currently keeping two workstations up to date via a USB flash drive, and have had, variously, both good and bad luck. Here are some questions: 1. I understand the idea, finally, of using a "bare" repo on the fiash drive, at least in part. But what will I do if the bare repo fails to merge because two versions are pushed or pulled to it from the two machines, of a file. I've wasted a bit of time and now have gotten "meld" installed as the mergetool. Still, sometimes even that doesn't work. Today I have two flash drives in use, one that was working fine to update from one machine, but won't even accept a file from the other. I have clumsily deleted the old version from the USB drive, and copied over the other version, done git rm <oldfile> git add <file> and git commit -a, but the file refuses to install. I'm not going to ask this as a primary question, because I think I need to just understand the underlying idea of using a bare repo, and not editing it at all. 2. I have had poor luck with push. 3. For this simple usage, is it even useful to think about branches, and if so, how should branches be used? 4. Is it wiser to fetch than to pull? I have seen this suggested, but don't understand the use of fetch. Here is a rough idea of what I think I need to do now. Please comment on any ommissions or problems: At home, on my primarly workstation: 1. cd to a directory with a good tree (perhaps ~/org) already under git control. 2. insert the USB drive (I have a label "BLUE" on my usb drive. On my gnome/ubuntu box, it automounts as /media/BLUE) 3. git clone --bare . /media/BLUE/org.git 4. git remote add BLUE /media/BLUE/org.git 5. ?? git push BLUE (master?) Now at work, I am on the other workstation: 1. git clone /media/BLUE/org.git 2. can I now do this?: git remote add BLUE /media/BLUE/org.git 2. work 3. git push BLUE ??? 4. Back at home 1. git fetch BLUE ?? or git pull BLUE ?? I am confused at a couple of points here. Much of the above I have gleaned from three posts by Bernt Hansen. Other sources on line include some postings on the very problem of syncing machines using git. Can I pull from /media/BLUE/org.git ? Well, perhaps this is enough confusion for now. Thanks for all the suggestions on this list. I think it's going to work, and I'll expand this to other directories as well. Alan -- Alan Davis It is undesirable to believe a proposition when there is no ground whatsoever for supposing it is true. ---- Bertrand Russell They are ill discoverers that think there is no land, when they can see nothing but sea. ---- Sir Francis Bacon [-- Attachment #1.2: Type: text/html, Size: 3035 bytes --] [-- Attachment #2: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
> Here is a rough idea of what I think I need to do now. Please comment > on any ommissions or problems: > > At home, on my primarly workstation: > 1. cd to a directory with a good tree (perhaps ~/org) already under git > control. > 2. insert the USB drive (I have a label "BLUE" on my usb drive. On my > gnome/ubuntu box, it automounts as /media/BLUE) > 3. git clone --bare . /media/BLUE/org.git > 4. git remote add BLUE /media/BLUE/org.git > 5. ?? git push BLUE (master?) > > Now at work, I am on the other workstation: > 1. git clone /media/BLUE/org.git > 2. can I now do this?: git remote add BLUE /media/BLUE/org.git > 2. work > 3. git push BLUE ??? > 4. > > Back at home > 1. git fetch BLUE ?? or git pull BLUE ?? > > > > I am confused at a couple of points here. > > Much of the above I have gleaned from three posts by Bernt Hansen. > Other sources on line include some postings on the very problem of > syncing machines using git. > > Can I pull from /media/BLUE/org.git ? > Alan, Not being a regular git user, I can't help directly with which commands you need to use. However, you might find http://www.netsplit.com/2009/02/23/revision-control-systems-suck/ entertaining. If you have a git repo that contains a "correct" working version, I would suggest that you start from scratch with that. As Bernt suggested you should create a repo with no working trees on your usb stick. This will just contain the repo i.e. .git and nothing else. In bzr you can use push to update your repo on the USB stick, so the .git contains all your changes. Note this only updates the repo, you won't see any of your files in the directory on the usb stick containing the repo (they are all in the .git repo). I think that part of the proble is that push in git doesn't work like you might expect (see the ranting link above). You may need to use got clone the first time you edn your changes, after that I think push should work. Take your usb stick to Machine B and create a working branch from your usb stick. In bzr this would be something like: bzr branch /media/usbstick/my_git_repo/ ~/Documents/org In git I think you need to use clone, with a similar syntax This would create a working copy in ~/Documents/org. Note that bzr would want to create the org directory, so whatever target directory you choose shouldn't exist initially. You can then work on your org files on Computer B and do a git commit when you have finished. In bzr a simple bzr push would update the repo on your usb stick and I think that got works the same way. You can then take your usb stick to Computer A and do a git pull to get your changes. When you have finished working on Computer A doing a git commit and a git push should update the repo on the usb stick. I have almost finished an article on how I use bzr to keep my org files in sync. I am aware that most people using org probably use git, so I have been trying to give my examples using both bzr and git. However, I too find some aspects of git confusing. If we can sort out the correct way to use git, I promise to finish my article and send it to worg! Ian.
Hi Alan, The best way to test drive all this stuff is just make some throw away repos to play with. $ mkdir /tmp/junk $ cd /path/to/your/org/git/repo $ git clone --bare . /tmp/junk/org.git $ cd /tmp/junk $ git clone org.git home $ git clone org.git work Now you have 3 repos in /tmp/junk work - pretends to be your repo at work home - pretends to be your repo at home org.git - your bare repo on the usb stick Now cd work, do stuff, git commit and git push then cd home, git pull, do more work, git commit, git push etc. Since these are just junk repos for experimenting you don't have to worry about messing them up and you can just rm -rf /tmp/junk when you're done. Comments follow: "Alan E. Davis" <lngndvs@gmail.com> writes: > Regarding the synchronizing of directories on two or more machines, using a USB Stick. Further questions after a bit of experimentation. > > I am currently keeping two workstations up to date via a USB flash drive, and have had, variously, both good and bad luck. Here are some questions: > > 1. I understand the idea, finally, of using a "bare" repo on the fiash drive, at least in part. But what will I do if the bare repo fails to merge because two versions are pushed or pulled to it from > the two machines, of a file. I've wasted a bit of time and now have gotten "meld" installed as the mergetool. Still, sometimes even that doesn't work. Today I have two flash drives in use, one that > was working fine to update from one machine, but won't even accept a file from the other. I have clumsily deleted the old version from the USB drive, and copied over the other version, done git rm > <oldfile> git add <file> and git commit -a, but the file refuses to install. I'm not going to ask this as a primary question, because I think I need to just understand the underlying idea of using a > bare repo, and not editing it at all. > You never merge on the bare repo. You do all of the merging on your working copies (home or work). Then pushes to the USB stick are always fast forward changes which just work. If you rebase and rewrite history you can force update on the usb stick with push -f -- just make sure you really want to overwrite the history on the usb stick with what you have now before you decide to do that. > > 2. I have had poor luck with push. > > 3. For this simple usage, is it even useful to think about branches, and if so, how should branches be used? I use topic branches all the time. If I want to put a branch on the sub stick I use: $ git push usb my-branch When you fetch from the usb repo it will create any new branches as usb/my-branch. You can also delete branches when you're done with them with $ git push usb :my-branch to remove it from the usb stick repo. To remove them from your working directory later you can use $ git remote prune usb which finds any remote branch names (usb/*) that exist in your working directory that no longer appear on the remote (usb stick) and deletes them from your working directory repo. > > > 4. Is it wiser to fetch than to pull? I have seen this suggested, but don't understand the use of fetch. pull = fetch + merge (or fetch + rebase) depending on the branch setup. I personally fetch first, and if git status stays it's a fast forward merge then I pull. > > > Here is a rough idea of what I think I need to do now. Please comment on any ommissions or problems: > > At home, on my primarly workstation: > 1. cd to a directory with a good tree (perhaps ~/org) already under git control. > 2. insert the USB drive (I have a label "BLUE" on my usb drive. On my gnome/ubuntu box, it automounts as /media/BLUE) > 3. git clone --bare . /media/BLUE/org.git This creates the repo with all of your branches in this working directory. > > 4. git remote add BLUE /media/BLUE/org.git > 5. ?? git push BLUE (master?) You don't need this after the clone - the new clone on the usb drive is up to date - it doesn't hurt though :) > > > Now at work, I am on the other workstation: > 1. git clone /media/BLUE/org.git > 2. can I now do this?: git remote add BLUE /media/BLUE/org.git After you clone the repo in step 1 the remote is added automatically with the name 'origin'. This would add a second remote (at the same location) but with a different name (BLUE). You really don't need to do this -- you can just use the remote 'origin' but again it doesn't hurt anything. > > 2. work > 3. git push BLUE ??? That pushes any new commits on master back to your BLUE remote. The push will fail if the update is not a fast forward. (ie if you added stuff to the usb stick from somewhere else since you fetched last then the push will fail). In that case you need to fetch + merge first (git pull) and resolve any conflicts you might have. > 4. > > Back at home > 1. git fetch BLUE ?? or git pull BLUE ?? > I would just do git pull (which is fetch + merge) If you fetch only you'll have this: o--o--H (tip master on home) \ o--o--W (time of usb/master with new commits from work) and after a fetch you can easily see this in gitk $ git gitk master origin/master (or if you don't have tons of branches just gitk --all) If you pull it will advance H (your master on the home repo) so it is at W. This is normally what you want to do. > > I am confused at a couple of points here. > > Much of the above I have gleaned from three posts by Bernt Hansen. Other sources on line include some postings on the very problem of syncing machines using git. > > Can I pull from /media/BLUE/org.git ? Yes you can (and for this setup I would recommend that as your normal mode of operation). AT work: $ git pull BLUE [*1*] <hack> <hack> <hack> <commit> <commit> <commit> $ git push BLUE <pull usb stick and go home> At home: <plug in usb stick> $ git pull BLUE <hack> <hack> <hack> <commit> <commit> <commit> $ git push BLUE <pull usb stick and go to work> <go to step [*1*]> > > Well, perhaps this is enough confusion for now. Thanks for all the suggestions on this list. I think it's going to work, and I'll expand this to other directories as well. As I said up front - just play with it in /tmp until you're comfortable. Regards, Bernt
Bernt Hansen <bernt@norang.ca> writes: > Hi Alan, > > The best way to test drive all this stuff is just make some throw away > repos to play with. > > $ mkdir /tmp/junk > $ cd /path/to/your/org/git/repo > $ git clone --bare . /tmp/junk/org.git > $ cd /tmp/junk > $ git clone org.git home > $ git clone org.git work > > Now you have 3 repos in /tmp/junk > work - pretends to be your repo at work > home - pretends to be your repo at home > org.git - your bare repo on the usb stick I'll stay with monotone for this exact reason and purpos. It's great with USB, FAT and so on. No mess since three years now and it has the best of all user interfaces. So here, again, my monotone advertising: No thinking and reading and asking and than again reading... - just using. That's what a SCMS is for. The docs (just one PDF) will get you started after 10 minutes and you'll only have refer to the docs in very rare cases in the future because of mtns UI. You'll not even have to add your key file to ssh-agent by hand - monotone does that for you once it knows about it. Don't add something - just commit... I only use git with servers on the net, where it plays great. Also, the `git gui' is one of the best GUIs for RCSs around. For the USB stick case, it's worth to mention, that monotone needs no .mtn-ignore file, just to know, that *~ files have to be ignored. Permissions are handled (even if the stick is FAT formated) as well as empty directories. Simply the best designed RCS around IMHO. No need to say, that monotone handles copys and renames (with history). USB: $ cd org/ $ mtn -d /path/to/desired/localdb db init $ touch file.c $ mtn add file.c $ mtn commit -m'message' Now the USB: $ cp /path/to/desired/localdb /media/BLUE That's all. The first time we sync with /media/BLUE/database, we tell monotone, to use this repo as the default. No fiddling with `remotes', `origin'... $ mtn sync --set-default /media/BLUE/localdb Bang - you're done once for ever. # On the other computer: $ cp /media/BLUE/localdb /path/to/desired/localdb $ mtn -d /path/to/desired/localdb co org $ cd org # edit add and so on $ mtn commit -m'message' $ mtn sync --set-default /media/BLUE/localdb Later on just call $ mtn sync Databases are small (in my tests _much_ smaller than git or mercurial repos), can even be accessed using SQL (it's a sqlite database) and extend it's functionality through LUA (per workspace), trust is managed per workspace... One feature I like with monotone is the _MTN/log file. You may gather commit messages while working, which makes it realy easy to document your work in great detail and keeps you documenting them. Never forget to document a change or the reason for it anymore. There's a little elisp file I wrote make `add-change-log-entry' search for _MTN/log and use it. I've bound `mtn-add-change-log-entry' to F8 (see http://www.emacswiki.org/cgi-bin/emacs/sr-monotone.el). I even use monotone and git in conjunction a lot. Monotone for USB, git for the servers (since I have to). While git has great features, those are not what I need for my workflow. git always throws warnings and errors here, when I try to `git clone --bare' on FAT formated USB sticks (didn't try with the new 1.6.1.3 version, that's in Debian testing since a week). Regards, -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de
Sebastian Rose <sebastian_rose@gmx.de> writes:
> git always throws warnings and errors here, when I try to `git clone
> --bare' on FAT formated USB sticks (didn't try with the new 1.6.1.3
> version, that's in Debian testing since a week).
The only issue I ran into was when I mounted the USB stick with Linux's
default options. I need to specify the option shortname=mixed so that
it doesn't create 'head' instead of 'HEAD' in the repo on the USB stick.
,----[ part of my /etc/fstab ]
| /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0
`----
After that everything worked great for me.
-Bernt
Bernt Hansen <bernt@norang.ca> writes: > Sebastian Rose <sebastian_rose@gmx.de> writes: > >> git always throws warnings and errors here, when I try to `git clone >> --bare' on FAT formated USB sticks (didn't try with the new 1.6.1.3 >> version, that's in Debian testing since a week). > > The only issue I ran into was when I mounted the USB stick with Linux's > default options. I need to specify the option shortname=mixed so that > it doesn't create 'head' instead of 'HEAD' in the repo on the USB stick. Aaaahaaa, Bernt is our git god :) That's exactly the reason for failing to create repos it seems. I remember, it head to do with `HEAD'! Thanks a lot. Now I only have to find out how to add that option to a modern system, that uses no fstab for USB devices. Google should shed light on this quickly. Even if I like monotone, I still don't like to use two systems for one project. Now I can use git for git projects, which is nice. Thanks Bernt! > ,----[ part of my /etc/fstab ] > | /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0 > `---- > > After that everything worked great for me. > > -Bernt > This was one of those days I learned more on the emacs-orgmode mailinglist, than in `real' life :) where I met no unicorn again. Regards, -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de
>> ,----[ part of my /etc/fstab ]
>> | /dev/sdb1 /usb vfat defaults,user,noauto,shortname=mixed 0 0
>> `----
>>
>> After that everything worked great for me.
>>
>> -Bernt
>>
>
> This was one of those days I learned more on the emacs-orgmode
> mailinglist, than in `real' life :) where I met no unicorn again.
Start gconf-editor and navigate to
system->storage->default_options->vfat
edit the key 'mount_options' and change it's value to:
[shortname=mixed,uid=]
That's it.
Now, indeed,
git clone -l --no-hardlinks --bare org/ /media/BLUE/git/org
works like a charm.
Thanks again Bernt!
Best,
--
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.: +49 (0)511 - 36 58 472
Fax: +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http: www.emma-stil.de
[-- Attachment #1.1: Type: text/plain, Size: 1485 bytes --] Thank you Bernt (and Sebastian): I now understand that it is necessary to pull the changes to the alternate tree before pushing. This will make a big difference in the future, I believe. It worked as advertized on the /tmp/junk experiment. I think the other point I had missed, that would be necessary in an FAQ or tutorial, is that it is necessary to initially clone each of the working trees, on each machine, from the bare repo on the USB flash drive. Then it now makes sense to me to name that as org.git, to distinguish it as a bare repo. And once the working trees are cloned from there, then the org.git on the USB drive is recognized automatically as "origin". That point eluded me. And that git pull will perhaps automatically find origin. Meld is starting to make sense too. Thought it would be nicer to have a tool that would be able to make simple updates from two edits on the same file if they don't conflict. Usually, this will not be the case. Now, is it useful to use the switches on an ext2 formatted USB drive, as follows? $ git clone -l --no-hardlinks --bare . /path/to/usb/stick Thank you again, Alan -- Alan Davis "An inviscid theory of flow renders the screw useless, but the need for one non-existent." ---Lord Raleigh (John William Strutt), or else his son, who was also a scientist. It is undesirable to believe a proposition when there is no ground whatsoever for supposing it is true. ---- Bertrand Russell [-- Attachment #1.2: Type: text/html, Size: 1755 bytes --] [-- Attachment #2: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 485 bytes --] One more point: May I ask for an example of a case when branching would make sense in the context of this synchronization usage of Git? Alan -- Alan Davis "An inviscid theory of flow renders the screw useless, but the need for one non-existent." ---Lord Raleigh (John William Strutt), or else his son, who was also a scientist. It is undesirable to believe a proposition when there is no ground whatsoever for supposing it is true. ---- Bertrand Russell [-- Attachment #1.2: Type: text/html, Size: 568 bytes --] [-- Attachment #2: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
"Alan E. Davis" <lngndvs@gmail.com> writes: > Thank you Bernt (and Sebastian): > I'm just trying to help :) > > I now understand that it is necessary to pull the changes to the alternate tree before pushing. This will make a big > difference in the future, I believe. It worked as advertized on the /tmp/junk experiment. Great! > > > I think the other point I had missed, that would be necessary in an FAQ or tutorial, is that it is necessary to initially > clone each of the working trees, on each machine, from the bare repo on the USB flash drive. Then it now makes sense to > me to name that as org.git, to distinguish it as a bare repo. And once the working trees are cloned from there, then the > org.git on the USB drive is recognized automatically as "origin". That point eluded me. And that git pull will perhaps > automatically find origin. git pull and git push use the default remote 'origin' if none is specified. > > Meld is starting to make sense too. Thought it would be nicer to have a tool that would be able to make simple updates > from two edits on the same file if they don't conflict. Usually, this will not be the case. > > Now, is it useful to use the switches on an ext2 formatted USB drive, as follows? > > $ git clone -l --no-hardlinks --bare . /path/to/usb/stick I've never used -l --no-hardlinks when creating repos on my usb stuck. vfat filesystems don't support hard links and you can't make use of hard links across filesystems. There is lots of information available from git man pages (ie. git clone --help) which describes what all of the options do. Regards, Bernt
"Alan E. Davis" <lngndvs@gmail.com> writes:
> One more point:
>
> May I ask for an example of a case when branching would make sense in
> the context of this synchronization usage of Git?
Here are a couple:
I don't use multiple branches for my org repos. But I do use branches
extensively on coding projects.
------------------------------------------------------------------------
I code for a living. When working on a project I make a branch for a
topic during development and keep the changes related to that topic
isolated on the topic branch until they are ready to be merged into the
main development branch.
My repo looks something like this:
o--o--o--o--A (master - main development branch)
Then I start a new topic creating a branch at A
o--o--o--o--A (master)
\
o--o--B (topic B)
New work can be added to the master branch as other development topics
are merged in
o--o--o--o--A--o--o (master)
\
o--o--B (topic B)
Now when I need to take this code with me I push master and the topic
branch(es) to the usb stick so I can continue working on them offline.
I'm free to continue development on my laptop and move the changes back
to my workstation.
When I merge the topic branch into the main branch I delete the topic
(and remove it from the usb stick repo). The topic branch stays as a
set of discreet commits all directly related to the topic. Commits for
other topics go on other branches (yes I have branches that are simply 1
commit). Branches are cheap and easy in git. I rarely work directly on
the master branch.
Having the flexibility to keep topic branches clean and isolated from
other changes is a huge help when developing multiple features on a
project. You can merge in only the topics that are ready and keep
working on the others. You are free to merge topic branches into the
main branch in whatever order makes sense for the project.
------------------------------------------------------------------------
On another project I have 68 topic branches which are merged into 4
integration branches in various combinations.
I only push the master, and 4 integration branches to the usb stick. I
can recreate any topic branch easily from the integration branch history
and I find it alot easier to manage all of these branches by only
tracking the integration branches on the usb stick.
------------------------------------------------------------------------
Another example is code for a website. If this is deployed on a test
webserver and a production webserver you can easily set up 3 branches as
follows:
o--o--o--o--o--o--o--o master (common code)
\ \
\ o--o--o--o test-config
\
o--o--o prod-config
where test-config is the set of configuration changes to make the
website work on the test environment and prod-config is the set of
changes to make the system work in production.
You would normally want all 3 branches available so that if you make
some change that required updating configuration information on the test
and prod branch you can keep the changes isolated on the appropriate
configuration branch.
To actually run the code in test you make an temporary integration
branch (test) at master and merge in the test-config branch. The result
should be ready to use on your test environment. When you're done
testing you can simply delete the test branch. It's a throw-away since
you can recreate it again easily as needed.
------------------------------------------------------------------------
I don't use this added flexibility on my org-mode repos. I don't have
topics where it makes sense to isolate changes while organizing things.
I use git with org-mode mainly as a safety net so I can easily do oops
type edits, as a backup of my org notes, and an easy way to synchronize
between my workstation and laptop. My organizational notes are all over
the place by nature and trying to separate that into discreet topics in
org-mode doesn't make any sense to me.
Does any of that help?
-Bernt
Bernt Hansen <bernt@norang.ca> writes:
>> $ git clone -l --no-hardlinks --bare . /path/to/usb/stick
>
> I've never used -l --no-hardlinks when creating repos on my usb stuck.
> vfat filesystems don't support hard links and you can't make use of
> hard links across filesystems.
That's true :)
I just copy this from my every-day-git.org. Everything I don't work on
anymore goes there to keep the number of workspaces at a minimum. I tend
to start a lot of little projects as test balloons (or just out of
curiousity) and keep them for reference. I'm always afraid to lose some
trick I found and that does not make it into one of my real projects :)
But even then, --no-hardlinks is not needed. It's a bad habbit even, since
I waste disk space that way. Removing .git in my workspace will never
remove any of the cloned (local, on same filesystem) repos, since files
_are_ hard links, and the data is reachable as long, as at least one
hard link exists (that's the difference between hard links and symbolic
links).
At least that's how I understand hard links on Linux.
`du' does take that into account:
$ mkdir test
$ cd test
$ touch file.c
$ cat /some/file > link.c
$ du -h
16K .
$ ln file.c link.c
$ du -h
16K .
$ ln link.c link2.c
$ du -h
16K .
$ ls -l
insgesamt 36
-rw-r--r-- 3 sebastian sebastian 8988 1. Mär 16:02 file.c
-rw-r--r-- 3 sebastian sebastian 8988 1. Mär 16:02 link2.c
-rw-r--r-- 3 sebastian sebastian 8988 1. Mär 16:02 link.c
No matter how many hard links I add: the disk usage stays the
same. One more point for git!
OK, I'll adjust my habbits :)
Best,
--
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.: +49 (0)511 - 36 58 472
Fax: +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http: www.emma-stil.de