SparkleShare

Christopher Browne cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Tue Feb 14 02:22:36 UTC 2012


On Mon, Feb 13, 2012 at 8:32 PM, Jason Nicolaides <voidpointer-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> What about a lighter-weight systray-type app instead of the full on
> gnome-panel?  Something like stalonetray?
>
> http://stalonetray.sourceforge.net/

Oh, excellent, thanks ever so much for pointing that out.  On Debian,
it depends solely on libc, libx11, and libxpm4, which are all
sufficiently broadly used that they're already around.

stalonetray evidently stands for "standalone tray," which is not
ridiculously anti-intuitive, but it was not notably obvious that such
a thing existed :-(.

[Mussing around for a bit...]

*Very* interesting.  I hooked this up to one of my repos on GitHub.

The Mono daemon sits around watching the local copy in ~/SparkleShare.

Any time a process alters files within a project, it:
a) invokes "git add --all"
b) figures out what was changed,
c) runs "git commit" to indicate the files altered, then
d) git push origin master to push the change over to the source Git repo.

It is extremely "commit-happy"...

As a bit of "torture", I set up a series of processes to create some files:

1.  create some files
 for i in `seq 111`; echo "test" > $i; sleep 3; done &

2.  remove some files
 for i in `seq 111`; rm $i; sleep 4; done &

And I set a few instances of this running in
~/SparkleShare/oh-my-zsh/messing-around

You can actually see the effects here:
https://github.com/cbbrowne/oh-my-zsh/commits/master

It's a rubbish little test, but I don't object to people seeing it :-).

Boy, that's commit-happy, but it seems to do what I'd fully expect it to do.

The mono process is pretty lardful:
VIRT = 249m
RES = 46m

I wonder how the interaction takes place if you have any conflicts in
cases where:

a) There are two instances of SparkleShare on two hosts, and users are
introducing conflicting changes

b) Someone introduces different changes via merging something in from
another Git repo.

I'm content to leave those as unknowns for now.

In this example, everything's pretty public, because by default,
"free" GitHub accounts are only available for public-facing projects.
It takes jumping through *some* additional hoops to get a Git server
running that is suitably private to store private information.

SparkleShare clearly does work, at some level, and represents a
plausible experiment for a DropBox alternative.  I'm not sure how far
it is from being treated as a realistic alternative.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list