On Mon, 14 Feb 2011 13:43:30 -0500 Mike Blumenkrantz <m...@zentific.com> wrote:
> On Mon, 14 Feb 2011 23:47:37 +0530 > Amitav Mohanty <amitavmohant...@gmail.com> wrote: > > > On 02/14/2011 01:42 PM, Mike Blumenkrantz wrote: > > > On Mon, 14 Feb 2011 13:35:05 +0530 > > > Amitav Mohanty<amitavmohant...@gmail.com> wrote: > > > > > >> Hello > > >> > > >> I would like to discuss my idea for a GSOC project. I want to > > >> implement support for version control systems into enlightenment > > >> file manager. The interface shall be a right click menu option > > >> for "VCS" in the file manager. The menu option in turn shall > > >> expand to provide further options. I am targetting the following > > >> version control systems: > > >> - git > > >> - mercurial > > >> - subversion > > >> - cvs > > >> - darcs > > >> - bazaar > > >> I would like to know your views in this regard. > > >> > > >> Regards, > > >> Amitav > > >> > > > What method would you be planning to use for this integration? > > > It's all well to say that you want to implement support, but I > > > think you will need to be a bit more detailed in your idea. > > > > > Well, svn support is in kde as kdesvn. > > http://kdesvn.alwins-world.de/ <http://kdesvn.alwins-world.de/> > > It uses subversion C API directly, instead of parsing svn client > > output. I talked on #svn and they suggest using the API specified in > > subversion/include/*.h . > > > > So far my idea of the implementation is harnessing that API to > > implement svn support for subversion in e_fm. > This is good. > > > > For git, I am thinking of using libgit2. http://libgit2.github.com/ > Looks good as well. > > > > Mercurial and bazaar use python. I have to look into calling python > > functions in C. > Libpython. It's a huge pain, however, so my strong suggestion is to > save these for after you get svn+git working (plus those are the two > that we actually use ;)) > > > > Regards, > > Amitav > Your idea sounds reasonable, and I think it would be very cool. As > everyone knows, however, efm is a monstrosity (Seb says: "Raster at > his best") that will very likely be scrapped for parts and rewritten > in the (near) future. This would be another good project! > > My suggestion for your work here is to start by writing a vfs library > that you can hook into with efm. This would allow abstraction and > easy addition of new fstypes (sshfs, for example) in the future. > Perhaps this library could also have an abstraction for exporting vfs > nodes to a unified format (with properties) that can be easily used > by a file manager, allowing your work in efm to be as minimal and > portable as possible for future versions. > Might help to look at the old evfs and entropy work. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
