On 11/4/2011 11:48 AM, Alek Paunov wrote:
Hi Nolan, Stephan,

I think that this is doable for a restricted subclass of usage scenarios (these
conforming workflow style cited by Stephan above + bunch of other restrictions).

We can benefit the fantastic opportunity of sqlite as fossil artifacts
container - I think that it is possible to be implemented git protocol enabled
python server with dulwich [1] on top of the fossil db, once we are able to
manage fossil/git commit hashes dictionary in additional db table. Hg-git [2]
also uses similar approach (but client side, It seems to me that server side is
the easier one).

Does hg have something git's rebase and other history rewriting operations ?

If not, how do hg and the synchronizer (dulwich?) cope when the git repository they talk to undergoes such a rewrite ?

This claim of 'lossless conversion of changesets' is certainly something of interest.

Hm ... given that "This plugin was originally developed by the folks at GitHub", maybe we can interest them in doing similar for fossil ?


As Fossil API, for the proof of the concept, the server can use the JSON API,
Stephan ?

Kind Regards,
Alek

[1] http://git.samba.org/?p=jelmer/dulwich.git
[2] http://hg-git.github.com/

P.S. github != git, maybe tickets and wikis can be synchronized too (to some
level) using the gihub API.



--
Andreas Kupries
Senior Tcl Developer
ActiveState, The Dynamic Language Experts

P: 778.786.1122
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Get insights on Open Source and Dynamic Languages at www.activestate.com/blog
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to