mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2012-11-12 10:40:09 -04:00
commit 520457e7ab
8 changed files with 92 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/design/assistant/blog/day_126__mr_watson_come_here/comment_2_8eb366ae7efb347bd3bbd9a98e0821b3._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.27"
subject="comment 2"
date="2012-11-12T02:39:19Z"
content="""
AFAIK, yenc can use xml characters like < and > in its encoding.
"""]]

10
doc/design/assistant/blog/day_128__last_xmpp_day/comment_1_fd8c1d6358cb50f4dad8ba11d33d861f._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmqVi9eQjkZt8EC-byTXJ8TnY7VyOHzW2s"
nickname="Zahary"
subject="Pairing on the local network"
date="2012-11-12T11:39:17Z"
content="""
Joey, How does pairing on the local network work btw?
Now that you have experience intercepting and relaying the git pack output maybe you can use UDP broadcast on the local network for a truly fast sync.
With dropbox, I'm often syncing working copies of software projects between several VMs so I can test the code on all platforms before committing. I've found that to be faster (for builds) then using a VM shared folders, network shares, etc.
"""]]

8
doc/design/assistant/blog/day_128__last_xmpp_day/comment_2_43664b73c71c41d71bc95e665f128106._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://phil.0x539.de/"
nickname="Philipp Kern"
subject="comment 2"
date="2012-11-12T11:50:42Z"
content="""
Developing something new based on IPv4 UDP broadcast seems to be insane. IPv6 link-local multicast should be available virtually anywhere. XMPP relies on TCP and a central server to guarantee that a single packet is not split up, which would need quite some protocol engineering to get right over lossy UDP (e.g. segmentation, flow control, congestion avoidance). But TCP as discovered using mDNS might work… Still needs some kind of authentication / encryption, though.
"""]]

11
doc/design/assistant/blog/day_128__last_xmpp_day/comment_3_d369b04f686009a9dbb57b999107a55e._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmqVi9eQjkZt8EC-byTXJ8TnY7VyOHzW2s"
nickname="Zahary"
subject="Jingle"
date="2012-11-12T12:00:50Z"
content="""
Also, you probably know about Jingle:
http://en.wikipedia.org/wiki/Jingle_(protocol)
What are you thoughts about it? I guess it would have been harder to use the Google C++ library from Haskell and full mesh peer-to-peer is certainly more complicated than using the XMPP server to effectively multicast to all paired clients.
"""]]

8
doc/design/assistant/blog/day_128__last_xmpp_day/comment_4_095855d301e7ccd3689ffe507cfb63ee._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmqVi9eQjkZt8EC-byTXJ8TnY7VyOHzW2s"
nickname="Zahary"
subject="@Philipp Kern"
date="2012-11-12T12:13:33Z"
content="""
Alright, I stand corrected, although I'm aware of some libraries that have already solved the problem so you don't really have to implement reliable UDP from scratch: http://code.google.com/p/openpgm/
"""]]

9
doc/design/assistant/blog/day_128__last_xmpp_day/comment_5_da7b0586b0b28e1e0fe4126f6543a7bc._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="http://phil.0x539.de/"
nickname="Philipp Kern"
subject="comment 5"
date="2012-11-12T12:50:26Z"
content="""
To quote the website (emphasis mine):
> PGM is appropriate for applications that require duplicate-free multicast data delivery from multiple sources to multiple receivers. *PGM does not support acknowledged delivery, nor does it guarantee ordering of packets from multiple senders.*
"""]]

15
doc/forum/Does_git-annex_version_big_files__63__/comment_3_32de3501feedce51b43ed9dcc399c7a9._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="karhun"
ip="99.20.248.32"
subject="comment 3"
date="2012-11-12T05:58:16Z"
content="""
Hi
I have one more follow up question.
So git-annex versions files as I understand. Is it possible to use it without file versioning and just use it as a sync tool. I realize that there are example scenarios to demonstrate it however I would like to disable versioning if possible because I am intending to use it on large folders with big binary type files.
thanks
"""]]

23
doc/forum/Using_Linux_static_builds/comment_3_64506833dad0202626239e00d1eb6490._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="http://colberg.org/"
ip="2001:470:1d:4d4:2d4b:7654:2c00:b95c"
subject="comment 3"
date="2012-11-12T05:05:39Z"
content="""
Hi Florian,
I maintain a makefile for GNU/Linux systems that builds git-annex from scratch using a single command.
git clone http://git.colberg.org/packages.git
nice make -f packages.mk CONCURRENCY_LEVEL=16 PREFIX=$HOME/usr/rhel6-x64_64 install-git-annex
The makefile fetches pre-compiled GHC 6.x (x86_64), which works on old systems (e.g. RHEL 5), builds a recent GHC 7.x from source, a minimal Haskell environment with cabal-install, and finally git-annex. I have succesfully compiled git-annex on RHEL 5.x and 6.x, and CentOS 6.x.
If the build fails using the system's GCC, there is also a newer GCC in the same makefile:
nice make -f packages.mk CONCURRENCY_LEVEL=16 PREFIX=$HOME/usr/rhel6-x64_64 install-gcc
Regards,
Peter
"""]]