It seems you have a plan set out for you. If you manage to get task sharing
working using git, more to you! I still think it's not the greatest idea,
but I'd rather see somebody try it than us argue about it for a few days.

Best of luck!


On Tue, Apr 2, 2013 at 12:56 PM, אנטולי קרסנר <[email protected]> wrote:

> I just checked what Snowy is... sounds useful, but the Gnome Live page
> hasn't been touched for long time and the FAQ says it's not stable yet
> and not safe to trust.
>
> I agree git is not meant for sharing, but here's the idea I have in
> mind:
>
> Task sharing is not simple file sharing, so I can't let users share the
> task files manually. The task management application uses git behind the
> scenes, just like SparkleShare uses git for file sharing. There
> shouldn't be any conflicts because program logic takes care of sharing,
> sync, giving tasks to employees, getting "task done" signals from them,
> receiving tasks from supervisor, etc. No need to use git directly. If
> there's a conflict, it means a bug. A problem in program logic.
>
> The advantage is that sharing tasks becomes extremely easy. Getting your
> own local repo and a remote repo for task sharing is extremely easy and
> accessible. Once you set the application to use a given repo, you don't
> need to touch git.
>
> XMPP has the advantage you can see people's avatars and use Jabber to
> instant-message the people you work with, but this can be made to work
> as an addition, in parallel to git.
>
> Backup and version management and very important in projects, so using
> git also allows very easy backup and control of versions and project
> status.
>
> And finally, using git makes changes to the application backend very
> easy. git allows me to play with file sharing and sync features and
> change the implementation, without affecting the user or resetting the
> user's task database or making the user create new
> repos/accounts/folders.
>
> - Anatoly
>
> On ג', 2013-04-02 at 12:29 -0400, Jasper St. Pierre wrote:
> > git isn't designed as a sharing protocol. It's a source control tool.
> > People have tried to take some of the versioning technology behind git
> > and adapt it to other things (SparkleShare, there are some git-backed
> > issue trackers, etc.)
> >
> >
> > As a simple example, what happens when you have a merge conflict?
> > There's a miscommunication, and one guy sets the task from OPEN to
> > DONE, and another guy sets it from OPEN to INPROGRESS.
> >
> >
> > When they try to share tasks, git is going to fail and ask them to
> > edit a file with:
> >
> > <<<<<<<<<<<<<<<<
> >
> > DONE
> > ================
> >
> > INPROGRESS
> >
> > >>>>>>>>>>>>>>>>
> >
> >
> > unless you're smart about how you present merge conflicts.
> >
> >
> > This is just an example, and I could come up with a large number of
> > other reasons why git's power is a deficiency when trying to build a
> > usable simple sharing system. I don't believe in the technology behind
> > git as a simple way to share stuff. It's too tied to source code and
> > programmers. I think a simple pub/sub model, either using XMPP, or an
> > open-source service (Snowy), or something else, is simpler and the
> > easier way to go.
> >
> >
> >
> > On Tue, Apr 2, 2013 at 12:25 PM, אנטולי קרסנר <[email protected]>
> > wrote:
> >         Hi,
> >
> >         This is a somewhat technical question, I hope this is the
> >         right place
> >         for it.
> >
> >         I'm writing a GTK application which manages tasks and
> >         projects. At the
> >         moment it's more or less like GTG (Getting Things Gnome). I
> >         want to add
> >         task sharing, and I've been thinking what's the right way to
> >         do that.
> >
> >         I checked what other people do. GTG uses the XMPP pubsub
> >         extension
> >         (publish & subscribe), which seems to do the job, but it's not
> >         exactly
> >         designed for sharing tasks. It does work, but it requires you
> >         to setup
> >         the server.
> >
> >         I've been thinking and I found another idea: use a git
> >         repository.
> >
> >         This way people can easily watch how projects develop - this
> >         way we
> >         easily achieve the publish&subscribe capability - and sharing
> >         tasks
> >         between team members is as easy as working with git, which is
> >         already
> >         very common. Task sync is simple sync of files in the repo.
> >         And it
> >         doesn't require any extra work: starting a new local git repo
> >         is
> >         extremely easy by typing "git init", and starting a repo on a
> >         server is
> >         done by creating a user on gitorious and creating a repo
> >         there.
> >
> >         Some sites don't offer private repos for free, but encryption
> >         will be
> >         used anyway to allow maximal privacy anyway, so it shouldn't
> >         be a
> >         problem. (GitLab offers 10 private repos for no charge if you
> >         really
> >         need 100% privacy)
> >
> >         I'd like to hear more ideas and make a wise decision, which
> >         tool is the
> >         best one for task sharing. Git sounds very good to me, but I'm
> >         not an
> >         expert (just a software engineering student, actually).
> >
> >
> >         - Anatoly
> >
> >         _______________________________________________
> >         desktop-devel-list mailing list
> >         [email protected]
> >         https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> > --
> >   Jasper
> >
>
>
>


-- 
  Jasper
_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to