Thank you for taking the time to do this.
On Sun, Jun 12, 2011 at 11:52, Richard Hartmann
wrote:
> * no use strict in validate_metadata?
How embarassing! Thank you for pointing that out. I have no idea how
that happened. I *always* start writing my perl scripts with 'use
strict; use warnings;
On Sun, Apr 10, 2011 at 16:43, Harley J Pig wrote:
> https://github.com/harleypig/gitperms
I have had some time to actually have a quick look at your script,
now. Disclaimer: I didn't run it, yet.
I have a few questions/comments:
* no use strict in validate_metadata?
* validate_metadata uses
On Sun, Apr 10, 2011 at 18:12, Richard Hartmann
wrote:
> Done.
Thanks.
--
Harley J Pig
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
On Mon, Apr 11, 2011 at 02:07, Harley J Pig wrote:
> I'm not subscribed to that list, go ahead and post it if you would. Thank
> you.
Done.
Richard
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
On Sun, Apr 10, 2011 at 09:48, Richard Hartmann
wrote:
> Are you willing to bounce that onto the git list or should I do so?
I'm not subscribed to that list, go ahead and post it if you would. Thank you.
--
Harley J Pig
___
vcs-home mailing list
vcs-h
On Sun, Apr 10, 2011 at 16:43, Harley J Pig wrote:
> You can
> find it at https://github.com/harleypig/gitperms
Are you willing to bounce that onto the git list or should I do so?
RIchard
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://li
I've written a metastore clone for a project where we need to store a
linux distribution in version control (legacy code). I'm also using
it for my personal vcs-home stuff. It is a naive and bluntly
straightforward way to do this, but it seems to be working. You can
find it at https://github.com
On Sat, Apr 9, 2011 at 04:42, Christophe-Marie Duquesne
wrote:
> git-annex does location tracking. Even if you delete the link, the file is
> still there and other repositories know what repositories have the file. If
> you want to be sure the file is always reachable, you have to force a
> repos
I'll try to gather things I can answer to:
I see you include fuse.py - http://code.google.com/p/fusepy/ - in your repo.
> how does it compare to fuse-python -
> http://pypi.python.org/pypi/fuse-python ?
>
fusepy is written with ctypes while fuse-python is a full-blown C extension.
At first, I was
Hi
I see there have been some good thoughts given about this. I am
currently on vacation in a place where I do not have internet access.
I'll come back to you in a week.
Regards,
Christophe-Marie
___
vcs-home mailing list
vcs-home@lists.madduck.net
http
On Sun, 3 Apr 2011 11:18:05 -0400
Joey Hess wrote:
> Dieter Plaetinck wrote:
>
> > I think having support for this in git-annex would be very useful,
> > even if it's not that efficient: if this can be dealt with in
> > git-annex, individual "higherlevel" projects like sharebox and
> > dvcs-auto
Richard Hartmann wrote:
> I know Joey pondered this as well, you will find some references on
> git-annex' ikiwiki. This is needed for S3 in the medium term, anyway.
>
> Basically, the plan is to encrypt the files with a symmetric key and
> then allow access to that key via other keys. That way, y
Dieter Plaetinck wrote:
> I think having support for this in git-annex would be very useful,
> even if it's not that efficient: if this can be dealt with in
> git-annex, individual "higherlevel" projects like sharebox and
> dvcs-autosync have less headaches. Not to mention
> sharebox/dvcs-autosyn
On Sun, Apr 3, 2011 at 13:18, Rene Mayrhofer wrote:
> I've also been thinking about transparent encryption for git/git-annex/bup
> backends, but this is not even in a real design phase yet. If anybody is
> interested in discussing the issues involved with backing up to a
> potentially untrusted r
On Sun, Apr 3, 2011 at 11:35, Dieter Plaetinck wrote:
> - centralized: have 1 (or more) remotes that always keep a copy of the files
> which are being removed on all other remotes, these would be backup-nodes,
> they don't follow the strict "always in sync" rule that applies to the
> regular n
On Sat, 2 Apr 2011 23:19:52 -0400
Joey Hess wrote:
> Dieter Plaetinck wrote:
> > @Joey: you mentioned you think inotify might be a better
> > backend/paradigm for this than fuse, so do you think implementing
> > git-annex in something like dvcs-autosync is feasible? and/or
> > preferable?
>
> Fe
Dieter Plaetinck wrote:
> @Joey: you mentioned you think inotify might be a better
> backend/paradigm for this than fuse, so do you think implementing
> git-annex in something like dvcs-autosync is feasible? and/or
> preferable?
Feasable? Certianly. Preferable? I'm in the "let a thousand flowers
b
I see you include fuse.py - http://code.google.com/p/fusepy/ - in your repo.
how does it compare to fuse-python - http://pypi.python.org/pypi/fuse-python ?
@Joey: you mentioned you think inotify might be a better backend/paradigm for
this than fuse, so do you think implementing git-annex in somet
On Thu, Mar 31, 2011 at 8:04 PM, Dieter Plaetinck wrote:
> you also need to do various git/git-annex commands, or am I missing something?
Ideally, that would be only at set up time.
> I quite like dvcs-autosync, but it indeed lacks space-efficient storage of
> big files.
> I would like to try i
On Thu, 31 Mar 2011 18:56:54 +0200
Christophe-Marie Duquesne wrote:
> Hi,
>
> I am currently writing a FUSE file system based on git-annex for
> replicating binary files on several machines. I thought I could share
> it here in order to get some ideas and contributors.
>
> What are your goals?
Christophe-Marie Duquesne wrote:
> I am currently writing a FUSE file system based on git-annex for
> replicating binary files on several machines. I thought I could share
> it here in order to get some ideas and contributors.
Wow, you have completely anticipated a blog post I was gonna make in a
Hi,
I am currently writing a FUSE file system based on git-annex for
replicating binary files on several machines. I thought I could share
it here in order to get some ideas and contributors.
What are your goals?
Seamless synchronization "à la dropbox".
Ability to use with big binary files such a
22 matches
Mail list logo
